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[57] ABSTRACT 

An electronic sourcing system includes a computer that 
maintains a catalog database of data including product 
information (such as product identification and descriptive 
information) relating to catalog items available from vendor 
product catalogs, and a means for building (generating) a 
requisition including at least one requisitioned item. Infor- 
mation at least partially identifying an item desired to be 
requisitioned is entered by a user, and utilized by a means for 
searching the database for catalog items matching that 
information and for selecting at least one catalog item 
located as a result of the search. Text describing the catalog 
items, and images of the items, may be viewed. Data 
identifying selected catalog items are communicated to the 
requisition building means, which generates a requisition 
including entries for items corresponding to the selected 
catalog items. The system checks the availability in one or 
more inventory locations of the corresponding desired cata- 
log items, and generates one or more purchase orders for 
desired items from inventory locations stocking the items. 

29 Claims, 5 Drawing Sheets 
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ELECTRONIC SOURCING SYSTEM lion with the requisition/purchasing system. They also do 

not provide the capability for a user to search a database 
This application is a continuation of U.S. application Ser. containing two or more vendor catalogs, and then to transfer 
No. 08/288,577 filed on Aug. 10, 1994. information about the items selected as a result of such 

S searches into a requisition/purchasing system such as Fisher 
BACKGROUND OF THE INVENTION RIMS for building a requisition for the catalog items. 

This invention relates to systems and methods for inter- Computer systems that are capable of searching databases 
facing product information, such as is typically found in c°ntammg • Product cata log of a particular vendor, for 
vendor catalogs that are provided to customers, and , n example on CD-ROM are also known Such systems can 
requisition/purchasing systems and methods that may use 10 sear f h { <* ^er requested .nformation about products and 

the results of searches of product information. crea,e °*». " » * he , user <»« P" nt or « in *°™ 

, . .... . . cases, facsimile directly to a vendor. The known computer 

There are a number of known requisition/purchasing ^ for vendor 

catalogs are Limited in that 

systems that manage and process requisitions ; and purchase oo , one ^ vendof ca , a , fa accessible (0 a usef at a 
orders. One such system is the Fisher Scientific Requ*mon , s jven d[ne ^ are alsQ Umited fa tha , , h can onl aMte 
and Inventory Management System ( Fisher RIMS ), &n or(jer within (he licular vendor ^ da(abase . 
described in co-pending patent application Ser. No. 08/042, canno[ it6ms (0 be requisitioned from a dalabase 

168, filed Apr. 2, 1993, issued as U.S. Pat. No. 5 712,989 on conla ; ni mul(i le catalogs or interact with a requis i tion/ 
Jan. 28, 1998, and assigned to Fisher Scientific Company of purchasing system (such as Fisher RIMS) t0 creale a pur . 
Pittsburgh, Pa., the dtsclosure of which is mcorporated 20 chase ord er or orders including the items located from tha. 
herein by reference. As its title suggests. Fisher RIMS can sourc i ng operation. 

also manage inventory. In the Fisher RIMS system, requi- _ ,, ,,' .... , .. ... 
sition records are created from a real-time interaction Thus, " * ould b ° des,r * le t0 P r0Vlde f ln , ele f on,c 
between a host computer (generally a mainframe) and a so " rcin 8 svs * m lhat P rovide * 4 ™ Mns for '"nsfernng 
local computer (generally al a customer site), with each M '"formation between a requisiUon/purchasing system that 
computer using data from its own respective database of * ma y us % the resu ' te of , a of Product.nformat.on and 

inventory in conjunction with information entered by a 1 m « ans for volumes ° f product informaUon 

' * # *• *u i i - « such as would be included in a vendor product catalog or 

customer service representative operating the local com- k & 

puter. By accessing its respective database, each computer ca a °^ s ' 

can build and transmit to the other computer communica- 30 11 would also be desirable to provide such an electronic 

tions blocks of data relating to a particular requisition of an sourcing system that is capable of searching a database 

item in inventory (or to the management of the inventory containing at least two vendor product catalogs for product 

itself). The other computer can then use the received data to information. 

continue processing of the requisition. Thus, requisition It would further be desirable to provide such an electronic 

records are created from a real-time interaction between the 35 sourcing system that is capable of searching a database of 

host and local computers, with each computer using data catalog items contain in at least two vendor product catalogs, 

from its respective database in conjunction with information selecting particular items located, and transferring informa- 

entered by a customer service representative operating the tion about the items selected (for example, a catalog number 

local computer. and a vendor identifier, such as vendor name and/or vendor 

Other requisition/purchasing systems can be grouped 40 number) to a requisition/purchasing system for inclusion in 

broadly into four classes. First, requisition management a requisition generated by the system, 

systems licensed to corporations purchasing for their own It would further be desirable to provide an electronic 

use include ORION software (from Medical Management sourcing system that is capable of creating an order list 

Systems), ENTERPRISE software (from ESI), and NOVA including items located as the result of a catalog database 

software (from Johnson & Johnson). Second, there exist 45 search and transferring that order list of desired catalog 

systems provided by distributors for transmitting orders to items to a requisition/purchasing system for inclusion of the 

them in proprietary formats. Such systems include QUICK- catalog items as entries in a requisition generated by the 

LINK (from Abbott), ASAP system (from Baxter) and system. 
LIGHTNING system (from Fisher Scientific). Third, soft- 

ware packages licensed by software developers to customers 50 SUMMARY OF THE INVENTION 

and/or suppliers enable the transmission of customer pur- In view of the foregoing, it is an object of this invention 

chase orders as EDI purchase orders (in ANSI X.12 format). to provide an electronic sourcing method and system thai 

Examples of such systems include ON-CALL EDI (from provides a user with the capability of searching a database 

TSI International), EDI Express software (from General containing data (including product/vendor identification, 

Electric Information Services) and GETRAN software 55 and other product information) relating to items available 

(from Sterling Software). Fourth, comprehensive business from at least two vendor product catalogs, and the capability 

management packages such as REAL WORLD software of transferring the product information for desired catalog 

(from Real World Corporation of Concord, N.H.) and ASK items obtained as a result of the search to a requisition/ 

software (from The ASK Group) contain a purchasing purchasing system for use in generating a requisition includ- 

module to create replenishment orders when inventoried eo ing entries for the desired catalog items, 

items fall below restocking points. The same purchasing n [ & also an object of this invention to provide an 

module can also be used to place spot orders for products electronic sourcing system that provides a means for 

keyed in by the customer's purchasing personnel. bi-directionally transferring information between a 

None of these known requisition/purchasing systems requisition/purchasing system that may use the results of a 

(including Fisher RIMS), however, provides a capability for 65 search of such product information, and a means for search- 

a user readily to search for and locate information about the ing large volumes of product information such as would be 

products that may be requisitioned and ordered in connec- included in a vendor product catalog. 
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It is a further object of this invention to provide an 
electronic sourcing system capable of creating an order list 
including desired catalog items located as the result of such 
a database search, and transferring that order list to a 
requisition/purchasing system for generating a requisition 
including entries for the desired catalog items. 

In accordance with the invention, an electronic sourcing 
system and method used by the system are provided. The 
system includes a computer that maintains a catalog data- 
base of data including product information (such as product 
identification information, and descriptive information) 
relating to catalog items available from vendor product 
catalogs, and a means for building (generating) a requisition 
including at least one requisitioned item. Information at least 
partially identifying an item desired to be requisitioned is 
entered by a user, and utilized by a means for searching the 
database for catalog items matching that information and for 
selecting at least one catalog item located as a result of the 
search. Text describing the catalog items, and images of the 
items, may be viewed. Data identifying selected catalog 
items are communicated to the requisition building means, 
which generates a requisition including entries for items 
corresponding to the selected catalog items. Additionally, 
the invention includes a means for checking the availability 
in one or more inventory locations of the corresponding 
desired catalog items, and for generating one or more 
purchase orders for desired items from inventory locations 
stocking the items. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects and advantages of the 
invention will be apparent from consideration of the follow- 
ing detailed description, taken in conjunction with the 
accompanying drawings, in which like reference characters 
refer to like parts throughout, and in which: 

FIG. 1A is a block diagram showing one exemplary 
embodiment of the overall system of the present invention; 

FIG. IB is a block diagram showing another exemplary 
embodiment of the overall system of the present invention; 

FIG. 1C is a block diagram showing a portion of the 
embodiment of FIG. 1A in greater detail; 

FIG. 2 is a block diagram showing the flow of control and 
interaction between the various programs and data screens 
of the programs used for requisition management and ven- 
dor catalog searching of the present invention; and 

FIG. 3 is a block diagram showing a portion of a system 
(Fisher RIMS) for requisition management, including the 
electronic sourcing system of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIGS. 1A and IB show preferred embodiments of the 
electronic sourcing system 5 of the present invention. As 
shown in FIG. 1A, a local computer 20, which is preferably 
located at or near a Customer site and the site of Just- In- 
Time ("JIT") Inventory, is preferably used by an on-site 
Customer Service Representative ("CSR") dedicated to a 
Customer to assist that Customer in requisitioning items 
needed. 

Local computer 20 includes conventional color monitor 
22 and alphanumerical keyboard 24 including twelve func- 
tion keys Fl, F2, . . . F12. Local computer 20 is also coupled 
to printer 26. 

Local computer 20 is preferably a conventional micro- 
computer (such as a 386-, 486- or Pentium -class personal 
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computer) capable of operating the required programs and of 
transmitting and receiving the required communications, 
running the OS/2 operating system 32 and also running the 
CICS OS/2 application 34, both of which are available from 
5 IBM. 

Electronic sourcing system 5 also includes a requisition/ 
purchasing system 40, preferably but not necessarily the 
Fisher RIMS system, and a search program 50 that is 
capable of searching through large volumes of information 

to quickly and accurately. Preferably but not necessarily, the 
Technical viewer 2 search program ("TV/2"), available from 
IBM, is used as search program 50, As shown in the 
embodiment of FIG, 1A, Fisher RIMS 40 and TV/2 search 
program 50 are run by local computer 20, 

15 Fisher RIMS system 40 is comprised of numerous pro- 
gram modules, including several programs 44, which oper- 
ate within CICS environment 34 of OS/2 operating system 
32. Programs 44 include, among others, Requisition Man- 
agement ("REQI") program 44 A, Inventory Sourcing pro- 

20 gram or programs 44B, Requisition Maintenance program 
44C, Customer Variable program 44D, and Order Header 
program 44E, each of which will later be described in 
greater detail. REQI program 44A is most often the RIMS 
program 44 that interfaces with TV/2 search program 50. 

25 Fisher RIMS system 40 also includes several Fisher 
RIMS databases 42. These databases 42 preferably include 
requisition databases 42A, inventory databases 42B, and 
customer-specific databases 42C, each maintained within 

3Q OS/2 operating system 32. 

Local computer 20 also preferably runs Shell program 52, 
which operates under search program 50 and is used to 
customize search program 50 to generate Order Lists 48 
(shown in FIG. 1C) with particular fields of formatted data 

35 about the items selected using search program 50. Local 
computer 20 is preferably capable of running both a RIMS 
program 44 and Shell program 52 at the same time (i.e., in 
a multi-tasking environment), but the user of local computer 
20 usually sees only RIMS program 44 or Shell program 52 

40 at one time in the foreground on monitor 22. 

Local computer 20 is also provided with a catalog data- 
base 36 comprised preferably of at least two vendor product 
catalogs. The catalogs, and hence catalog database 36, 
preferably include such information as part number, price, 

45 catalog number, vendor name or I.D., and vendor catalog 
number, as well as textual information and images of or 
relating to the catalog products. The nature of the business 
that the Customer using electronic sourcing system 5 con- 
ducts will determine which product catalogs are made a part 

50 of catalog database 36. 

A feature of the present invention is the ability to search 
multiple catalogs from different suppliers. For example, 
catalog database 36 can contain the catalog or catalogs 
published by a vendor Distributor, having Distributor's 

55 catalog numbers for all listed products and vendor manu- 
facturer's part numbers for many of the listed products. 
Catalog database 36 can further contain catalogs published 
by some of the vendor manufacturers, listing the manufac- 
turers' part numbers for certain products correspondingly 

60 listed in the Distributor's catalogs and for certain products 
not listed in the Distributor's catalogs. Catalog database 36 
can further contain catalogs published by outside suppliers, 
whether other manufacturers or other distributors, listing 
such vendor's products different from those in the Distribu- 

65 tor's catalogs. 

Where the Fisher RIMS system is in use with electronic 
sourcing system 5, a host computer 10 located at a Distribu- 
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tor site is also provided, as shown in FIG. 1A. Host computer 
10 controls all inventory, pricing and requisitioning opera- 
tions of the Distributor's regularly stocked items using host 
pricing and inventory databases 11. Host pricing and inven- 
tory databases 11 may include such information as: descrip- 
tions of the items and the quantities thereof available at a 
particular Distributor warehouse and at other Distributor 
warehouses; item records for each Product regularly sold by 
the Distributor; discount records by Customer; and cross- 
references from the Distributor's catalog number to its 
corresponding vendor's part (catalog) number and to similar 
corresponding catalog numbers of other vendors (suppliers 
or distributors) for the same Product. 

Host computer 10 and local computer 20 are preferably 
linked point-to-point or in a network employing the formats 
and protocols of IBM's System Network Architecture 
("SNA"). Host computer 10 can be substantially any main- 
frame or minicomputer capable of running the desired 
programs and conducting the required communications. 
Preferably, host computer 10 is a mainframe computer, such 
as an IBM Model 3090, running the MVS operating system, 
the MVS-CICS application and a Virtual Telecommunica- 
tion Access Method communications network. 

As shown in FIGS. 1C and 2, interface 60 is also a part 
of electronic sourcing interface system 5. Interface 60 com- 
municates shared data between requisition/purchasing sys- 
tem 40 and search program 50. Interface 60 is preferably 
based upon the dynamic data exchange ("DDE") protocol 
provided by OS/2 operating system 32. As shown in FIG. 2, 
interface 60 preferably includes three linking programs to 
interface requisition/purchasing system 40 and search pro- 
gram 50: ESRC program 70, ESCP program 80 and DDE 
LINK 90. 

A typical data exchange may begin with requisition/ 
purchasing system 40 (which, in the illustrated embodiment, 
is the Fisher RIMS system) requesting information from 
catalog database 36 via search program 50. Once a search by 
search program 50 has been completed, the selected infor- 
mation will be communicated to requisition/purchasing sys- 
tem 40 via interface 60. 

Alternatively, if the search of catalog database 36 is 
initiated from search program 50, the information selected 
from the search is returned to requisition/procurement sys- 
tem 40 via interface 60. 

The start up of electronic sourcing system 5 (FIG. 1A) 
may be user-initiated or automatically started when the 
operating system, preferably OS/2 system 32, is brought up 
on local computer 20. An application-name string 61 must 
be identified to label interface 60. As shown in FIG. 1C, 
electronic sourcing system 5 by convention will use 
"TV2V123," "TV2V124," "TV2V125," etc. as application 
names 61 supporting the user's requesting service. 

Preferably, application names 61 correspond to virtual 
terminal sessions that exist in the CICS system 34 of 
requisition/purchasing system 40. There will be a one-to-one 
correspondence between applications started (such as Shell 
52) and CICS virtual terminals in use at a location of 
requisition/procurement system 40 (such as REQI program 
44 A). Local computer 20 will query OS/2 operating system 
32 to determine the next application- name string 61 to create 
at start-up. The application -name strings 61 will be created 
in sequence with V123 being created first, V124 created 
second, etc. Each application will create only one applica- 
tion name-string 61 to support its user in the CICS envi- 
ronment 34. 

If the Fisher RIMS system has been selected as 
requisition/purchasing system 40, and the TV/2 search pro- 
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gram has been selected as search program 50, CICS OS/2 
applications 34 must share a workstation with a TV/2 search 
program 50. 

The data passed by interface 60 preferably comprise all or 

5 a subset of the following twelve fields: vendor name, vendor 
number, vendor part (catalog) number, product description, 
bid price, list price, keyword, page number, quantity, unit, 
catalog text, and catalog images. Because of the amount of 
data for catalog images present in database 36 and viewed on 

10 monitor 22, these data are usually not passed via interface 
60. Any of the above-listed fields may be filled by 
requisition/purchasing system 40 prior to requesting a search 
of catalog database 36 by search .-rogram 50. However, 
requisition/purchasing system 40 is not required to pass any 

15 data to search program 50. If a field is not passed, that field 
will be filled with spaces. The fields that are filled with data 
will assist search program 50 in executing its first search 
against a specific catalog contained in catalog database 36. 
A search priority exists when more than one field is 

20 provided by requisition/purchasing system 40. The priority 
is as follows: (1) part (catalog) number; (2) keyword; and (3) 
page number. The search will start with priority (1) and 
proceed through priority (3) in sequence until a search 
produces products matching the search criteria. At that time, 

25 the search will return the matching product information to 
requisition/purchasing system 40 and stop at the highest 
priority resulting in a match. 
The operation of electronic sourcing system 5 of the 

, Q present invention will now be more particularly described in 
the context of FIGS. 1A, 1C, 2 and 3. In FIGS. 2 and 3, the 
rectangles represent data screens as well as programs asso- 
ciated with those data screens. The rounded rectangles 
represent programs not associated with data screens such 

35 that, while these programs are running, the prior data screen 
may remain visible without, necessarily, being operational 
for the input of data. The programs associated with the data 
screens enable the user of local computer 20 to display and 
modify the contents of various tables associated with par- 

4Q ticular data screens. The following description illustrates the 
use of the Fisher RIMS system as requisition/purchasing 
system 40, and the TV/2 search program as search program 
50. However, it will be understood that the present invention 
is not limited to such system or program. 

45 Preferably, a user will start the electronic sourcing system 
5 from Fisher RIMS system 40. Requisitioning on Fisher 
RIMS system 40 in context of the electronic sourcing system 
5 of the present invention is illustrated in pertinent part in 
FIG. 3 (and is fully described in application Ser. No. 

50 08/042,168, now U.S. Pat. No. 5,712,989). As data (e.g., 
Account Number, Requisition Number and Stock Numbers) 
associated with a single requisition are entered through the 
various data screens on local computer 20, that computer 
creates a set of Requisition Tables (including a Requisition 

55 Item Table 46, shown in FIG. 1C) for that particular requi- 
sition. The Requisition Tables are stored in Requisition 
databases 42 A (shown in FIG. 1A), and can be accessed by 
local computer 20 using the Requisition Number to find the 
desired table. 

60 The first step in creating a requisition in Fisher RIMS 
system 40 involves entry by the user of information in the 
Order Header program 44D (shown in FIG. 1A), which has 
an associated Order Header data screen 100 (FIG. 3). A 
sample of an actual Order Header data screen 100 is set forth 

65 in Appendix I. The user enters an Account Number, which 
generally causes the correct name and address associated 
with that Account Number to be entered into the appropriate 
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fields of Order Header data screen 100. The user must also entering its distributor catalog or part number, if known, in 

enter a Requisition Number in the appropriate field of the the field below the STOCK NBR label on the appropriate 

Order Header screen 100. Various additional information line in Requisition Item Table 46 shown on Requisition 

may also be entered. management data screen 110. In the sample Requisition 

At the bottom of Order Header data screen 100 are several 5 Management data screen 110 shown in Appendix II, the part 
fields that describe the function of various function keys. number 13246818F has been entered in the STOCK NBR 
Function keys F6, F9, and F10 all cause the system to jump field of Line 001. Once the user has entered such informa- 
to a new RIMS program 44 or data screen in Fisher RIMS lion at least partially describing a desired item on Requisi- 
system 40. For example, pressing the F9 key causes the tion Management data screen 110, he or she may wish to 
system to jump to RIMS Customer Variable program 44E 1Q initiate a search of catalog database 36 to find all the part 
(FIG. 1A) and its associated Customer Variable Header data numbers contained in catalog database 36 that match the part 
screen 104 (FIG. 3). Customer Variable Header program number entered or other information on Requisition Man- 
44E with its associated Customer Variable Header data age ment screen 110. If so, the user enters the letter "S" (for 
screen 104 allows the user to enter and edit information that "Select") on the line number of the item that he or she wishes 
the particular customer desires to be associated with the to search in catalog database 36. The letter "S" has been 
requisition due to requirements of the customer's internal entered to the left of line 001 on the sample Requisition 
accounting system or other systems. Pressing the F10 key Management data screen 110 shown in Appendix II. Any 
will cause the system to enter the Inventory Sourcing number of items, or no items, listed on Requisition Man- 
program or programs 44B. agement data screen 110 may be marked with M S." 

Pressing the F6 function key from the Order Header data 2Q a user may not always have information relating to the 

screen causes Fisher RIMS system 40 to jump to REQI catalog or part number for the particular items that are to be 

program 44A(FIG. 1A). The screen associated with REQI requisitioned using Fisher RIMS system 40. Or, the user 

program 44A is Requisition Management data screen 110 may have relevant information about an item from a par- 

(FIG. 3) illustrated in Appendix II. Within REQI program ti^ia,- vendor but may wish to locate information about the 

44A and its associated Requisition Management data screen 25 same or a similar product available from other vendors. Or, 

110, Requisition Item Table 46 (shown in FIG. 1C) is a the user may simply know the name of the item that he or 

graphical representation of a database table in which certain sne wishes to requisition. In any of these cases, the user 

fields are completed on a list of items that are to be listed, alternatively or additionally could enter text at least partially 

sourced and ordered. Representative Requisition Manage- describing the product to be requisitioned in the "DESC" 

ment data screens 110 showing a Requisition on Requisition 3Q field of Requisition Management data screen 110 (e.g., 

Item Table 46 are set forth in Appendices II, VIII and IX. It Appendix II). Then, the user would initiate the electronic 

should be appreciated that data about each item is stored in sourcing system 5 of the present invention to search the 

Requisition Item Table 46, some of which is displayed on the vendor product catalogs contained in catalog database 36. 

screens shown in Appendices II, VIII and IX. The data Alternatively, the user could initiate search program 50 of 

stored can additionally include customer variable data. That 35 electronic sourcing system 5 without having first entered 

is, the fields on Requisition Item Table 46 can be expanded information in RIMS system 40 about the product to be 

to include specific item details used by a particular customer, requisitioned. 

especially when reports from requisition databases are trans- Qnce the user has buiJt or paftially buih Requisition hem 

ferred to the customer's host computer (not shown). The Xable 46 by fining lhe linc numbers (entries) on Requisition 

field structure for these data is maintained in customer- 4Q Management data screen 110 and selecting those lines to be 

specific databases 42C. searched, he or she is now ready to initiate electronic 

The entire process of listing, sourcing and ordering prod- sourcing system 5. Pressing the Fll function key, which is 

ucts using Fisher RIMS system 40 can be completed without labelled "Catalog," from Requisition Management screen 

any reference to a search program 50. As described herein, no accesses electronic sourcing system 5. 

however, limited fields on specific items can be transmitted 45 Referring now to FIG. 2, after the user presses the Fl 1 key 

from Requisition Item Table 46 to search program 50, and on Requisition Management data screen 110 of Fisher RIMS 

more completed fields of the same or different items can be system 4^ Fisher RIMS system 40 wil , m 

received from the search program 50 into a Requisition Item control via XCTL 74 t0 ^ RC program 70 XCTL ?4 fa a 

Table 46. protocol within CICS application 34 that directs the execu- 

At the bottom of Requisition Management data screen 110 50 t ; on G f a pr0 gram, as would readily be understood by one of 

(FIG. 3), and Appendices II, VIII and IX) are several fields ordinary skill in the art. As control is passed from REQI 

which describe the function of various function keys (Fl, program 44A to ESRC program 70, ESRC-Comm-AREA 

F2, etc.). The user uses REQI program 44A and its associ- data struct ure 76 is passed. ESRC-Comm-AREA is a layout 

ated Requisition Management data screen 110 to enter the D f storage area in local computer 20 created by REQI 

catalog or part numbers and quantities of the various items 55 program 44A to pass data to ESRC program 70, as would 

being requisitioned. readily be understood by one of ordinary skill in the art. 

The Account Number and Requisition Number are auto- ESRC program 70 will then LINK 82 to ESCP program 80 

matically passed to REQI program 44A and its associated with ESCP-Comm-AREA 84. LINK 82 is a protocol within 

Requisition Management data screen 110, and displayed at CICS application 32 that directs the execution of a program, 

the top of the Requisition Management data screen 110 in 60 as would readily be understood by one of ordinary skill in 

the relevant fields. For example, in the exemplary Requisi- the art. Data at least partially describing one item desired to 

tion Management data screen 110 shown in Appendix II, the be requisitioned is passed to ESCP program 80 via LINK 82. 

number 218848 has been entered in the Account Number Thus, if there are five items to be passed to ESCP program 

field, and the notation "TEST NEW ONE" has been entered 80, there will be five LINKS 82 made. If no items are to be 

in the Requisition Number field. 65 passe d to ESCP program 80, only one LINK 82 is made to 

The user can next enter desired items and quantities for ESCP program 80. ESCP program 80 can return up to twenty 

the requisition. Each desired item may be identified by items per LINK 82; in other words, for each item desired to 
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be requisitioned up to twenty desired catalog items con- 
tained in catalog database 36 may be sent to REQI program 
44 A and its associated Requisition Management data screen 
110 of Fisher RIMS system 40. If a user chooses to terminate 
the sourcing process, ESRC program 70 would return to 
REQI program 44A and its associated Requisition Manage- 
ment data screen 110 without processing any of the records. 

ESCP program 80 links with Shell 52 and TV/2 search 
program 50 via DDE LINK 90. Shell 52 and TV/2 search 
program 50 search in catalog database 36 for the item or 
items desired to be requisitioned that has or have been 
passed from ESRC program 70 to ESCP program 80. 
Catalog database 36 contains the following fields: vendor 
name, vendor number, vendor part (catalog) number, prod- 
uct description, list price, page number, quantity, unit, cata- 
log text, and catalog images. Shell 52 and TV/2 search 
program 50 may, if desired, search the keyword field or any 
other field shown in Appendix VII. However, not all fields 
may appear on the monitor 22 of local computer 20, 
although they are stored in memory. 

After the user has pressed the Fll key from Requisition 
Management data screen 110 and control has been passed 
from REQI program 44A to Shell 52 and TV/2 search 
program 50, monitor 22 of local computer 20 will show a 
footer bar representative of Shell 52 at all times that the user 
is in the TV/2 search program 50. The footer bar, which also 
includes appropriate icons, is used to make choices within 
Shell 52. A sample of the footer bar (without the icons) 
representing Shell 52 is shown at the base of Appendices 
III- VII. In the screens of Appendices CI— VI, this footer bar 
is active to select functions. In the screen of Appendix VII, 
this footer bar is in the background and another footer bar is 
used to select functions. 

If the user has marked an item on Requisition Manage- 
ment data screen 110 with the designation "S," the entered 
data at least partially describing that item will be sent to 
Shell 52 and TV/2 search program 50A in the manner 
described above. TV/2 search program 50 will search cata- 
log database 36 for all items that match the search field sent 
over from REQI program 44A and Requisition Management 
data screen 110. When a search is performed in Shell 52 and 
search program 50, a Hit List 47 is produced, as indicated in 
FIG. 1C. The user would see on monitor 22 of local 
computer 20 a Hit List 47 screen representing limited data 
about all matching catalog items that were located in catalog 
database 36 as a result of the search. A sample Hit List 47 
produced from a search initiated when the entry "OVENS" 
is received as the description or keyword by search program 
50 from Requisition Item Table 46 is shown in Appendix III. 
Similar Hit Lists 47 are produced when various searches are 
performed from the Search Input screen shown in Appendix 
VII. When a Hit List 47 is depicted on monitor 22, the 
underlying catalog text and pictures (in either partial or 
complete form) are typically collected in a memory location 
for rapid viewing, printing or other use. 

When multiple catalogs are present in catalog database 
36, search program 50 contains a function associated with 
the catalog symbol of the footer bar and screen window (not 
shown) for selecting catalogs to be searched. For example, 
[he following choices might be available: 

1. Fisher General Catalog 93-94; 

2. Fairmont Supplies Catalog; 

3. NIST Standards Catalog; and 

4. Promega Biological Research Products Catalog. 
Fairmont and NIST catalogs list products not in the Fisher 

General Catalog, but many of the products listed in the 
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Promega catalog are also listed in the Fisher General Cata- 
log (identified by corresponding Fisher catalog numbers). If 
searching for a molecular biology product, the user would 
select the Fisher and Promega catalogs. TV/2 search pro- 

5 gram 50 would then concatenate those two catalogs to 
perform a keyword, catalog number or other subject search 
and generate a Hit List of pages (panels) from both catalogs 
where the searched-for items were found. Similarly, the user 
might select the Fisher and NIST catalogs when searching 
for quality control standards or might select the Fisher and 

1 Fairmont catalogs when searching for supplies. 

If the search is initiated from requisition/purchasing pro- 
gram 40, for example from the Requisition Management 
data screen 110 of the Fisher RIMS system, then the catalogs 
searched can be determined by the information provided. If, 

15 for example, Promega is indicated as the desired requisition 
item vendor, interface 60 would direct TV/2 search program 
50 to search the Fisher and Fairmont catalogs. If no catalog 
delimiting information is entered for the item desired to be 
requisitioned, interface 60 would be set up to search only the 

20 Fisher catalog or, alternatively, to search all catalogs in 
catalog database 36. 

Once Hit List 47 has been created by TV/2 search 
program 50, the user can view it and select particular ones 
of the located catalog items for Order List 48 that is being 

25 created in Shell 52, as shown in FIG. 1C. For example, a 
search for "Eco RI," a restriction enzyme, may have uncov- 
ered five entries in the Promega catalog (identified by 
Promega catalog numbers R6011, R6012, R6013, R6015 
and R401) and five entries in the Fisher catalog (identified 

30 by Fisher catalog numbers PRR6011, PRR6012, PRR6013, 
PRR6015 and PRR4014). If the user selected PRR6012 
from the Fisher catalog, Fisher catalog number PRR6012 
would be added as an entry to the Items Selected screen, 
with VN00000001 (identifying the vendor as distributor 

35 Fisher) accompanying it in the Order List 48. If the user 
instead selected the item identified by catalog number 
R6012 from the Promega catalog, then Promega catalog 
number R6012 would be added as an entry to the Items 
Selected screen, with VN00005860 (identifying the vendor 

40 as Promega) accompanying it in the Order List. In either 
case, the information transmitted to REQI program 44A of 
Fisher RIMS system 40 would also include description, list 
price and other information taken from the catalog database 
from which the selection was made. When the resultant 

4S requisition is sourced, however (as described below), Dis- 
tributor's mainframe host computer 10 would recognize the 
entry for the item from vendor Promega 's catalog (R6012, 
00005860) as corresponding to that same item available 
from Fisher's catalog (PRR6012, 00000001). The system 

50 thus would transmit back the Customer's contract price and 
availability for corresponding item PRR6012 as a type 03 
(regular Distributor) product available from one of distribu- 
tor's inventory locations. A purchase order then would be 
generated for this corresponding Distributor item as further 

55 described below. 

By contrast, an item selected from the Fairmont catalog 
would be transferred to Fisher RIMS system 40 with the 
vendor number for Fairmont, and would be recognized 
during inventory sourcing as either a type 07 product (that 

60 Distributor orders from Fairmont) or as a type 05 item (that 
Customer orders from Fairmont as an Administrative 
Purchase). In either of these two cases, a purchase order 
would be generated for an item, corresponding to a desired 
catalog item, that is identified by the same Fairmont catalog 

65 number that was requisitioned. 

After the desired item has been selected from the Hit List 
47 by double clicking on that item TV/2 search program 50 
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can be used to bring up for viewing on monitor 22, or However, not all of these fields are viewed on the Items 

printing on printer 26, images and text from the catalog page Selected screen. 

on which the item selected is located. For example, as shown If more than one item on Requisition Management data 

in Appendix HI, page 1106 of the Fisher catalog has been screen 110 had been marked with an "S," the process 

selected. If the user double clicks on highlighted page 1106, 5 described above is repeated. 

the text shown in Appendix IV (and related images, not If the user desires to do additional searching in catalog 

shown) would appear on monitor 22. On the sample screen database 36 that is not connected to catalog or other items 

shown in Appendix IV, the item that appears on page 1106 that have been listed on Requisition Management data 

of the Fisher catalog relates to Fisher Isotemp 800 Series screen 110 of Fisher RIMS system 40, he or she can click the 

Programmable Ovens. Conventional scroll bars appearing 10 box on footer bar of Shell 52 that is labelled "Search." Then, 

on the screen (not shown in Appendix IV) enable the user to a Search screen comes up on monitor 22 of local computer 

scroll through additional catalog information (text and/or 20. An exemplary Search screen is shown in Appendix VII. 

images) not yet displayed on the screen. An example of such In this screen, the usual footer bar is visible in the 

additional textual information is depicted on the screen background, but is not active. 

shown in Appendix V. 15 Using the Search screen, a user can search catalog data- 

On the screen of Appendix V, the vendor distributor's base 36 by page, text description, part number (where the 

catalog number ("Cat. No.") 13-246-818F is highlighted. user has the further option to search by Fisher part number, 

The catalog number of an item normally appears in blue in for example if Fisher is to be the desired vendor), Vendor 

a screen such as Appendix V. This blue lettering is used for pari number, vendor name (for vendors other than Fisher), or 

catalog numbers, trademarks, footnotes and other entries for 20 bulletin. Stock numbers specific to the customer can also be 

which database 36 contains additional information or cross- present in catalog database 36 and searched using the screen 

references (called hyperlinks). When a search is conducted of Appendix VII. "Bulletin" refers to an additional vendor 

and the catalog segments of the resultant hit list are publication wilh detailed product information that may not 

reviewed, the test corresponding to the search parameter is be included in a vendor catalog. Searching for information 

highlighted in red. Thus, in Appendix V, catalog number 25 contained in bulletins may be done by bulletin number, but 

1 3-246-8 18F (identified in the search) appears in red, while only if bulletins have been made a part of catalog database 

catalog number 13-246-838F and the trademark Isotemp 36. For purposes of this disclosure, bulletins when included 

each appear in blue. A word, vendor part number or catalog in a catalog database are considered a type of catalog, 

number located by the search will appear red, even if that After the user has entered the field to be searched on the 

word or number did not have an associated hyperlink (and 30 Search Screen, the user clicks on the "SEARCH" box near 

thus is not normally blue). the bottom of the Search Screen. A Hit List 47 indicating all 

When in search program 50, particular items selected can items from catalog database 36 that match the search field 

be added to an Order List 48 pending in Shell 52 and search that was entered on the Search Screen then is generated, 

program 50. When the Ordering portion of catalog text is Then, in a manner similar to that described previously, the 

viewed (as in Appendix V), particular items can be selected 35 user can scroll through the Hit List 47 and double click on 

so as to be added to the Order List 48 by double clicking on the catalog page or panel desired. The user may then also 

the highlighted catalog number (even if a different field was view the detailed information located on the catalog page 

also highlighted as a result of a search of catalog database that was selected from the Hit List 47. During the search, the 

36). The item is then added to an Order List 48 that is created user may also add additional items to the Order List 48 being 

in Shell 52 via a hypertext link. The items that are sent to the 40 built in Shell 52 if desired, whether those additional items 

Order List 48 are collected and shown on the Items Selected had been selected from the Hit List 47 or not, 

screen of Shell 52. An example of an Items Selected screen The Order List that the user has built in Shell 52 is 

of Shell 52 is shown in Appendix VI. The Items Selected maintained on the Items Selected screen, shown in Appendix 

screen depicts certain fields of Order List 48 that can be VI. From the Items Selected screen, the user can cancel the 

viewed and edited within search program 50. For example, 45 order by clicking on the "Cancel" box at the bottom of the 

Shell 52 permits the user via a pop-up window (not shown) screen, delete an item from the Order List 48 by moving the 

to select units, e.g. pack or case, and quantity to be ordered, pointer bar to the item to be deleted and then clicking on the 

e.g. two packs. Alternatively, the data in these fields can "Delete" box at the bottom of the screen, or delete all items 

default to one of the smallest unit and the units can be by clicking on the "Delete All" box. The user can also view 

changed when the order is reviewed in REQI program 44 A. 50 catalog text and images for a particular item by clicking on 

Additional fields on the same items are also present in the "Description" box. 

memory at this stage. Upon clicking on "Order" when the Once the user has completely built the Order List 48 

Items Selected screen (Appendix VI) is viewed, many or all within Shell 52 and TV/2 search program 50, he or she can 

of these fields on the items in the Order List are transmitted transmit it to Fisher RIMS system 40. This is accomplished 

back to REQI program 44A(via the programs of interface 60 55 by clicking on the "Order" box at the bottom of the Items 

shown in FIG. 2) to be added to the pending Requisition Selected screen to communicate the completed Order List 48 

Item Table 46. The sample Items Selected screen shown in to Fisher RIMS system 40. 

Appendix VI includes the Isotemp Oven with catalog num- The user may have selected no items, one item or several 

ber 13248 18F that was located as a result of the search for items from the catalogs contained in catalog database 36 by 

all items in catalog database 36 that match the part number 60 using TV/2 search program 50. If no items have been 

1 32468 18F that was entered in the STOCK NBR field of selected, the original items that were entered on Requisition 

REQI program 44A and its associated Requisition Manage- Item Table 46 of Requisition Management data screen 110 

ment data screen 110 of Fisher RIMS system 40. will remain on that screen and will continue to be processed 

The following fields are transferred to Order List 48 by Fisher RIMS system 40. If one or several desired catalog 

created in TV/2 search program 50: Vendor name, vendor 65 items were selected in TV/2 search program 50, the first item 

number, vendor part (catalog) number, product description, selected will replace the original item on Requisition Item 

list price, page number, quantity, unit and catalog text. Table 46 of Requisition Management data screen 110. Addi- 
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tional items that were selected from the search that was 
performed in TV/2 search program 50 will be added to 
Requisition Item Table 46 of Requisition Management data 
screen 110. 

Interface programs ESCP 80 and ESRC 70 (FIG. 2) are 5 
used to send data to REQI program 44A (FIG. 1A) and its 
associated Requisition Management data screen 110 (FIG. 
2) about the items that were selected from the search 
performed by TV/2 search program 50. To the user, it 
appears that all the items selected from the search are sent 
over to Fisher RIMS system 40 at the same time. However, 
ESCP program 80 receives multiple items from TV/2 search 
program 50, and then sends one item at a time to ESRC 
program 70. ESRC program 70 then waits until all items 
have been passed to it before sending data about the items 
to REQI program 44 A and its associated Requisition Man- 15 
agement screen 110 of Fisher RIMS system 40. The infor- 
mation transmitted to Requisition Management screen 110 
from the Order List built in TV/2 search program 50 and sent 
through ESCP program 80 and ESRC program 70 includes 
vendor name, vendor number, vendor part (catalog) number, 20 
product description, list price, page number, quantity, unit 
and catalog text. However, not all of the above-listed fields 
may be displayed on screen at all times. ESRC program 70 
passes control back to Fisher RIMS system 40 via XCTL78. 
The requisition number, customer identification and release 25 
number (or other data identifying the requisition) will be 
passed in MENU-Comm-AREA 56 to confirm that the 
returned data are associated with the proper requisition. 
MENU-Comm-AREA 56 is a layout of storage area within 
local computer 20, as one of ordinary skill in the art would 30 
readily understand. 

As previously indicated, multiple LINKS 82 may have 
been created between program ESRC 70 and program ESCP 
80 if multiple lines were selected (with the "S" symbol) in 
Requisition Management data screen 110. After completing 35 
the first search, and any additional searches initiated with the 
footer bar, an order list is created and returned to Requisition 
Item Data Table 46 associated with Requisition Manage- 
ment data screen 110. At this point, the next item is sent from 
a LINK 82 through program ESCP 80 and DDE LINK 90 to 40 
the TV/2 program 50, and a hit list resulting from the 
corresponding search is displayed on monitor 22. The pro- 
cess of searching, displaying, selecting and ordering is 
repeated until all of items stored by LINKS 82 have been 
sent to TV/2 program 50 and searched. At the end of each of 45 
these searches, an order list may be created and returned to 
Requisition Item Data Table 46 or cancelled. Once the last 
item is completed, ESRC program 70 passes control via 
XCTL 78, and a Requisition Management screen 110 is 
displayed, reflecting all of the additions and changes that 50 
have been made to the Requisition Item Data Table 46 
associated with that requisition. 

A limit is normally placed on the number of items of an 
order that may be returned to the Requisition Item Data 
Table 46. For example, if the maximum size in Requisition 55 
Item Data Table 46 is set at 200 lines, one could create a 
limit on the size of each order list at 20, 50, 100 or even 200. 
A corresponding limit can be placed on the number of 
LINKS 82 that can be established concurrently from the 
same requisition. Setting a limit of five LINKS 82 and forty 
items per order list would be one way of avoiding situations 
in which a Requisition Item Data Table 46 reaches its limit 
(e.g., 200 lines) before all of the searches (five) have been 
completed and order lists (five of forty items each) have 
been returned. 

At this point in the use of Fisher RIMS system 40, as 
many entries (lines) of Requisition Management data screen 



516 

14 

110 have been built up (some through use of electronic 
sourcing system 5) as are necessary to complete the requi- 
sition. A sample of such a Requisition Management data 
screen 110, in which four lines have been entered identifying 
desired items to be requisitioned (including catalog items 
located as a result of a catalogs search), is shown in 
Appendix VIII. The next step is that of inventory sourcing 
using RIMS inventory sourcing program or programs 44B in 
Fisher RIMS system 40, as shown in FIG. 3. Inventory 
sourcing is the process of determining what inventory will 
be used to fill the requisition. Pricing is also performed in 
this step when it is called for. Inventory sourcing in Fisher 
RIMS system 40 is performed on both local computer 20 and 
host computer 10. 

Within Fisher RIMS system 40, a Requisition Item Table 
46, as shown in Appendix VIII (similar to that shown in 
Appendix II, but including more items), can be inventory 
sourced by pressing the key F6 from REQI program 44A 
represented by Requisition Management data screen 110 
shown in Appendix VIII (and in Appendix II). Since inven- 
tory records on JIT items (type 01 and 06) are maintained in 
inventory database 42B, lines 002 and 004 in Appendix VIII 
show the availability of these items in inventory (49 items 
available for line 002, and 0 items available for line 004). 
After the F6 key has been pressed, host computer 10 
searches its host pricing and inventory databases for avail- 
ability of the various items listed on Requisition Manage- 
ment data screen 110 in different inventory locations (e.g., 
different warehouses) as described in further detail, below. 

After such inventory sourcing, and assuming that no 
errors occurred during sourcing (as indicated by decision 
step 116 in FIG. 3), the contract price, source (inventory) 
location and available quantity or other fields are commu- 
nicated back to computer 20 by host computer 10, and 
entered and displayed in the Requisition Management 
Screen. This can best be seen by comparing lines 001 and 

003 of Appendix VIII to Appendix IX, especially as to "QTY 
AVAIL" (quantity available), "LOC (inventory location) 
and price. As Appendix IX indicates, an inventory-sourced 
Requisition Item Table 46 typically contains the same items, 
but with more completed fields (including price, product 
type and inventory location). Moreover, as discussed above, 
an entry in an inventory-sourced Requisition Management 
screen may indicate for a requisitioned item a vendor and 
vendor catalog number that has been changed, from what 
was obtained from a catalog search, to a corresponding 
vendor and vendor catalog number for that item from 
another source (e.g., Fisher — which has its own catalog 
number for that manufacturer's item that Fisher distributes). 

For example, as shown in Appendix IX, product type "01" 
for the item on line 002 indicates that the requested requi- 
sition item is available as Distributor-owned inventory in the 
JIT inventory that the vendor/distributor maintains near 
local computer 20, either for the particular Customer or for 
a group of customers. Product type "06" for the item on line 

004 indicates that this item is available for the requisitioner 
employed by the Customer from inventory owned by Cus- 
tomer's purchasing department but managed by local com- 
puter 20. Product type "03" for the items on lines 001 and 

60 003 indicates that these are regular Distributor items that the 
communication between Distributor's host computer 10 and 
local computer 20 determined were available in sufficient 
quantity at one or another of Distributor's general ware- 
houses designated "DEL" and "EDC" in the location 
65 ("LOC") field. Product type "05" (not shown in Appendix 
IX) indicates that a requisitioned item is to be purchased by 
Customer directly from an outside supplier, using an Admin- 
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istrative Purchase Order that local computer 20 creates and 
prints (or transmits) for Customer. 

The inventory sourcing process described above also 
determines the net prices shown in Appendix IX for each 
item. TVpe 01 and type 03 items are priced by Distributor's 
host computer 10 searching host databases 11, which contain 
various formulae a ad tables of Distributor's pricing agree- 
ment with the Customer. Host computer 10 also prices any 
type 04 or type 07 item, if present. These prices were 
transmitted to local computer 20 along with the location and 
availability information for the type 01 items. Prices for type 
05 and 06 items are maintained in the local computer's 20 
own databases 42B and 42C. 

From Requisition Maintenance data screen 120, the CSR 
can accept all lines of the requisition — if all lines show the 
status "S M for sourced in the "STAT" field of Requisition 
Maintenance data screen 120 — by pressing the F6 function 
key. If item errors are found at step 116 in the data trans- 
mitted back to local computer 20 from host computer 10 
during the sourcing process, then those particular items for 
which error was found wilt be returned and displayed by 
local computer 20 in Requisition Management data screen 
110. 

Once a requisition has been inventory sourced and 
accepted by the CSR, it can be converted to one or more 
purchase orders, as represented by step 114 in FIG. 3. For 
example, the requisition represented by the Requisition Item 
Table 46 of Appendix IX, if accepted without further revi- 
sion by pressing function key F6 ("ACCEPT*), would result 
in the generation of the following three purchase orders: 

A. Line 002 would be ordered from on-site distributor- 
owned inventory; 

B. Line 004 would be ordered from on-site customer- 
owned inventory (a transfer internal to the customer); 
and 

C Lines 001 and 003 would be ordered, respectively, 
from Distributor's "DEL and "EDC" warehouses. 

Of these three purchase orders, Orders A (type "01") and 
C (type "03") are shared between host computer 10 and local 
computer 20 (as shown in FIG. 3). Upon execution of Order 
A, the inventory records on both computers for Distributor- 
owned JIT inventory are adjusted synchronously. A purchase 
order is generated by host computer 10 immediately there- 
after. Order B (type "06") is executed and stored only on 
local computer 20. Upon execution of Order B, the inven- 
tory record on local computer 20 is adjusted (the host 
computer contains no records on Customer-owned JIT 
inventory or on items ordered by Administrative Purchases). 
For Administrative Purchases (type 05 items), a purchase 
order is printed, and mailed or faxed, locally by computer 20 
as indicated at step 118 in FIG. 3, or via host computer 10 
via EDI (if EDI was selected in the Header of Appendix I 
and an EDI transfer arrangement existed with vendor). 

It is an important feature of the present invention that a 
requisition may be filled by searching and selecting from a 
catalog database of items, inventory sourced, and the result- 
ing requisition then divided into one or more purchase 
orders. This contrasts with known prior art CD-ROM cata- 
log systems in which only a single purchase order to a single 
supplier is built without reference to inventory records, and 
in which the information used to create the purchase order 
is limited to that contained in the product catalog of a single 
vendor. 

Electronic sourcing system 5 also contains the capability 
to log messages returned from inventory sourcing program 
or programs 44B of Fisher RIMS system 40. Messages will 
be logged for any of the following reasons: (1) part number 
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changes for line sent to ESCP program 80; (2) list price from 
inventory sourcing program 44B differs from list price 
returned from ESCP program 80; (3) vendor name from 
inventory sourcing program 44B differs from vendor name 

5 returned from ESCP program 80; (4) on a "master or 
blanket" order, in which local computer 20 tracks the 
amount of purchases against a blanket or cumulative sum 
available and/or in which there is limited access to products 
or limited access to certain users, the part has already been 

10 entered on another line; and (5) the maximum number of line 
items has been reached. 

Referring again to FIG. 2, a user is able to view the 
messages returned by pressing the ALT Fll function keys in 
REQI program 44A and its associated Requisition Manage - 

is ment screen 110 in Fisher RIMS system 40. After the ALT 
Fll keys have been pressed, REQI program 44A will link to 
ESMV program 112 via XCTL link 111 for displaying the 
message log created. ESMV program 112 is a function of 
Fisher RIMS system 40. ESMV program 112 allows the user 

20 lo page through the messages created and then to return to 
Requisition Management screen 110. A sample ESMV mes- 
sage screen associated with ESMV program 112 is shown in 
Appendix X. 

The first two messages of the message screen of Appendix 

25 X indicate that a part number for line 001, identified as part 
number 53610, was successfully added in substitution for a 
prior part originally entered as part number SI 00-06 (from 
the Fisher Scientific catalog). TTiese messages were gener- 
ated because the originally entered part (S100-06) did not 

30 exist in the Fisher catalog, but its corresponding part number 
S100-06 (that was located by another search in another 
catalog) did exist in that other cstslog. The next message 
indicates that the vendor for part number 53610 was 
changed in line 001 from "VN00000001 "—meaning that the 

35 originally requested vendor (Fisher) was changed. The next 
two messages indicate that two other part numbers (53620 
and 53650) were successfully added as lines 002 and 003. 

In the previous description, an exemplary embodiment 
has been described in which a Distributor CSR operates 

40 Fisher RIMS requisition/purchasing system 40 and IBM 
TV/2 search program 50 as part of a Just-In-Time activity 
for a particular customer, Customer. Electronic sourcing 
system 5 of the present invention may also be used, 
however, in other requisition and purchasing environments. 

45 In some embodiments, a Customer end user or a Customer 
purchasing employee operating REQI program 44A of 
Fisher RIMS system 40 may also operate TV/2 search 
program 50. Operating either from a terminal connected to 
local computer 20, or from a separate local computer net- 

50 worked with the CSR's local computer 20, such a Customer 
end user can select requisitioned items for inclusion in 
Requisition Item Table 46 by keystrokes viewing that screen 
and by searches in TV/2 search program 50 which are 
transmitted to the Requisition Item Table 46 via interface 60, 

55 as described above. Depending upon his or her authorization 
level and access code to Fisher RIMS system 40, the 
Customer purchasing employee may be able to source the 
final requisition and/or accept the sourced requisition, as 
shown in Appendix IX. If, however, the sourced requisition 

60 was split into more purchase orders than the Customer 
purchasing employee might prefer, the intervention of the 
Distributor CSR could be invoked to revise and re-source 
the requisition (causing, for example, certain items origi- 
nally sourced as type 01 products to be sourced for this order 

65 as corresponding type 03 products from a common Distribu- 
tor warehouse with other type 03 products on the 
requisition). The Customer end user may have authority only 
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to build the Requisition Item Table, but then calls the the Fairmont and NIST catalogs described above for the 

Distributor CSR or Customer purchasing employee to embodiment of FIG. 1A. The Distributor purchasing 

source and accept the requisition. employee can receive by phone or via Distributor's host 

As shown in FIG. IB, the present invention also has computer 210 requests for items not shown on Distributor's 

application to Distributor's regional customer service loca- 5 host databases either as regular products (type 03) or third 

lions where a large number of CSRs may be placing orders P ar ^ l j cras purchased for particular customers on a regular 

directly on Distributor's host computer 210 for thousands of basis ^ c 07 ;! cms )* Transmitting certain such require- 

different customers who call in. In that environment, search ments r t0 mc applicable Distributor purchasing employee can 

program 250, which preferably comprises TV/2 search pro- bc a functlon of the inventory sourcing routines of host 

gram 250, and catalog databases 236 are stored on file server 10 computer, or may be directed by the Distributor CSR inler- 

200. In this environment, file server 200 is a large personal fac «?g ^ £ 6 custome /- . 

computer, a work station or a mini -computer such as an IBM The Distributor purchasing employee can search appro- 

AS/400. Alternatively, the server 200 and a minicomputer P riale catalogs using TV-2 search program 250, and can 

(such as an IBM AS/400) can be independently connected to transfer the " Ilems Selected" to a product list in EASEL 

each local computer 200. Each CSR has a local personal is interface 254. The resultant list might display, for example, 

computer 220 having a monitor 222, a keyboard 224 and a su PP lier P art number » supplier, list price, product and catalog 

printer 226. Local computer 220 is provided with programs P a S e » Wlth access t0 other fields such 45 complete descrip- 

including requisition/purchasing program 240, Shell pro- tl0n < U P to 500 characters). The Distributor purchasing 

gram 252 and a graphic user interface 254 (preferably employee can then either forward the information to the 

EASEL Workbench program 254 for OS/2) for listing items. 20 CSR > customer end user or customer purchasing employee 

One or more of these may be copied from server 220 when who ^quested the item (to confirm that the requirement is 

needed. Work-in-progress requisitions 260 are established bein S met ) or contacl the supplier to confirm pricing and 

for each customer and are attached to graphic user interface availability. Once responses from either or both have been 

254. Server 200 maintains complete requisitions 242, in a obtained, the Distributor purchasing employee can use the 

manner similar to the manner in which local computer 20 25 itcra M in EASEL interface 254 to create one or more of the 

maintains requisition databases 42 in the embodiment following purchase orders: 

shown in FIG. 1A, an oide* from the customer to the supplier (an Admin- 
Normally, in such an environment, the CSR creates Order istrative Purchase); 
lists for customers by entering Distributor catalog numbers 2. an order from the customer to Distributor (for a type 07 
into graphic user interface 254 and connecting to the Dis- 30 product); and 

tributor mainframe 210 for price and availability. For this 3. an order from the Distributor to the supplier (usually 

purpose, each local computer is connected to host computer providing for direct shipment from the supplier to the 

210 via a phone/data line and either a gateway or a mini- customer or to a JIT site maintained by Distributor for 

computer acting as a local host. When a customer asks for the customer). 

products by manufacturer part number or a competitor's 35 From the foregoing description, it should be apparent that 

catalog number, the CSR has access to cross-reference files, the network arrangements of FIG. IB can be used to apply 

as earlier described, either maintained on the local host or the present invention in a variety of contexts. The context 

maintained on the Distributor host computer 210. will dictate which catalog databases 236 are provided on file 

Appropriate Distributor catalogs and manufacturer cata- server 200: in the regional CSR environment, Distributors 
logs then are consulted, using TV-2 search program 250 and 40 catalogs can be present with a variety of catalogs and 
proper selection of Distributor catalogs and of catalogs and bulletins from manufacturers that Distributor regularly rep- 
bulletins from manufacturers whose products Distributor resents and a limited selection of outside suppliers; and in 
regularly sells. Catalogs and bulletins are contained in the Distributor purchasing environment, the number of 
catalog database 236. The resultant lists of products are then outside supplier catalogs will be increased. The number of 
transferred by Shell program 252 to a work-in-progress 45 client (local) computers 220 and the number and size of 
requisition 260, and then entered from graphical user inter- catalog databases 236 will help dictate what size file server 
face 254 directly onto Distributor's mainframe computer 200 is required. The operating environment (regional CSR 
210 as orders from the applicable customer to Distributor. site, on-site CSR, on-site CSR networked with Customer 
The CSR, knowing which items are available from which end users and with purchaser personnel or Distributor pur- 
Distributor warehouse and direct -shipping supplier, then 50 chasing site) will also affect the catalog databases 236 
may divide the customer's requested items into multiple included, file server 200 size and requisition/purchasing 
orders, so as to assure that each order is completely filled by program 240 used. In some situations (e.g., purchasing) each 
a single shipment. In this regional environment, file server client computer has an independent copy of requisition/ 
200 or the minicomputer acting as local host can maintain purchasing program 240; in others (e.g., on-site CSR) a 
files of completed requisitions 242 which can be subse- 55 single copy of the requisition/purchasing program 240 is 
quently used for generating reports for customers in the maintained with associated local databases on the server 
region. Reports can be gene rated either from such local data 200. Where the requisition/purchasing program 240 and 
or from data periodically downloaded to the local host from local databases are maintained on file server 200, the local 
Distributor's host computer 210. database is updated after each use for the benefit of subse- 

Another environment where the present invention can be 60 quent users. For example, in an environment using Fisher 

used is in Distributor's purchasing department. The item RIMS for requisition/purchasing program 240, if a NIST 

lists created in that environment can include lists of items standard is selected using TV-2 search program 250 and 

Distributor does not regularly stock or purchase, but for ordered using Fisher RIMS 240 (as either a type 07 purchase 

which particular customers indicate a requirement to buy. from Distributer or a type 05 administrative purchase from 

The file server 200 in that environment contains TV-2 search 65 NIST), that item is available in the applicable database for 

program 250, EASEL graphical user interface 254 and subsequent requisitions. For example, a NIST standard 

multiple catalog databases 236 containing catalogs similar to ordered as a type 05 item will be stored in the local database 
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on file server 200, with NIST as the vendor for subsequent 
administrative purchases by Customer. A NIST standard 
ordered from Distributor as a type 07 item will be stored in 
Distributor's host databases as a type 07 available to Dis- 
tributor from NIST. The local databases on file server 200 
will also contain records of all items requisitioned and 
ordered, useful to transfer files to a Customer's computer 
(e.g., of purchase orders placed by that Customer in a day) 
or to generate reports for a Customer (e.g., or requisitions 
placed by each Customer department and/or budget number 
in a week). 
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Thus it is seen that an electronic sourcing system includ- 
ing means for Unking a requisition/purchasing system and a 
means for searching large volumes of information has been 
described. Persons skilled in the art will appreciate that the 
present invention can be practiced by other than the 
described embodiments, which are presented for the pur- 
poses of illustration and not of limitation, and the present 
invention is limited only by the claims which follow. 



APPENDIX I 



FISHER SCIENTIFIC RIMS 
REQUISITION HEADER 



08/05/94 
07:04:57 



RUSH CODE: 9 
TAX OVERRIDE: 



DATE; 
TIME: 
ACCT-NBR: 

COMPANY: 

REQ NBR: 
RELEASE: 

CALLER: 

ATTN: 

BILL TO: 

VENDOR: 

CREATED: 08-04-1994 STATUS: R 

RESPONSE; KEY(S): 

+F2: ADD F3: EXIT F4: UPDATE F5: REFRESH F6: ITEM F9: VAR F10: SRCE Fll: CHGPO F12: DEL 
13V123 

APPENDDC II 



NAME: 
ADDRESS: 



ORDER TYPE: R ORDER 
HOLD/REL: I 
FREIGHT OVERRIDE: N 

EDI PO TO HOST: N POA 855 

PRT ACK: Y NBR OF COPIES: 1 

ACK DELV CODE: P PRINT & DELTVER 
REQ DELV CODE: W WALK IN 
SERVICE CHARGE: 0.00 



UM PT STKRM XREF SPI 
CS 03 

QTY AVAIL; 



QTY AVAIL: 
QTY AVAIL: 
QTY AVAIL: 
QTY AVAIL: 



UNIT PRICE EXT PRICE 
0.00 0.00 
0 LOC: FSHR WHSE: BLW 



«*« REQUISITION MANAGEMENT SCREEN ' 

ACCT NBR: 218848 002 REQ NBR: TEST NEW ONE 
COMP: 1 REL NBR: 

S LINE STOCK NBR OTY 
001 13246818F 0 
DESC: 
002 
DESC: 
003 
DESC: 
004 
DESC: 
005 
DESC: 
RESPONSE: KEY(S): 
ALL ITEMS DISPLAYED 

F3: EXIT F6: SOURCE F7: BKWD F8: FWD F9: NEW F10: NONCAT Fll: CATALOG F12: CNCL 



LOC: 
LOC: 
LOC: 
LOC; 



WHSE; 
WHSE 
WHSE; 
WHSE; 



APPENDIX III 



ovens 
General 

(1106) Fuher Iwtcmp 800 Series Programmable Ovens 

(11 07) [so temp 700 Series Deluxe Lab Ovens 
(llOS)Isotemp 600 Standard Lab Ovens 

(1109) Fisher tsotcmp 500 Scries Economy Lab Ovens 

(1110) Gravity Convection Ovens 
(11 ll)Utility ovens 

(1112) Mechanicat Convection Ovens with Electronic Temperature 

(1 11 3) Gcncral -Purpose Ovens 

(1114) Heavy Duty Deluxe Ovens 
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-continued 



(1116) Large Capacity Model 2882A 

(1117) Standard Capacity Model 28 JA 

(11 18) Fisher Models 280 and 285 Vacuum Ovens 

(1119) NAPCO Vacuum ovens 

Help Catalogs Search Order List Minimize Clear Prev Next Exit 



APPENDIX IV 



(FSCU 06) Fisher Isotemp 800 Series Programmable Ovens 

Fisher feotempx 800 Series Programmable Ovens 
Three linear heat-up and cool-down stages 
Talking control panel 
Keypad and lighted graphics 
30° to 325° C range 
Rs-422 serial communications capability 

The latest technology at your fingertips. Accurate, easy-to-use controls allow you to program up to 3 heat- up stages 
and 3 cool -down stages linearly to provide the most appropriate conditions for your samples. Using the large 
keyboard, you can choose the heat-up or cool-down rate, the temperature you want for each stage, and the 
length of time you want the oven to hold each temperature. And, for projects requiring repeatability, 
you can duplicate (he settings at any time. 

Help Catalogs Search Order List Minimize Clear Prev Next Exit 



APPENDIX V 



Model 



(FSCU 06) Fisher feotemp 809 Series Programmable Ovens 
81 8F 838F 



16 x 12 x 16 (41 x 30 x 41 cm) 

156 lb. (71 kg) 

230 V 50/60 Hz 11.3 Amps 

13-246-818F 

3495.00 



Inside DxWxH 
Shp. Wt. 

Electrical Requirements 
Cat. No. 
Each 

Extra Shelves for 800 Series Ovens 

No-tip design. Move to any position in seconds. Full Depth Shelves: Chrome- Plated Steel 

Help Catalogs Search Order List Minimize Clear Prev Next 



18 x 18 x 20 (46 x 46 x 51 cm) 
195 lb. (88 kg) 
230 V 50/60 Hz 19 Amps 
13-246-838F 
3995.00 



Exit 



APPENDIX VI 



ITEMS SELECTED 



Part Number Description List Price 

13246818F ISOTEMP OVEN MDL818F 230 V 3495.00 

Help Cancel Delete Delete All Order Description 



APPENDIX VII 



SEARCH 



Page: 
Search For: 

Part Number: OFisher OVendor OCustomer 

Vfcndor Name: 
Bulletin: 

HELP SEARCH CANCEL CLEAR USER DATA EXTENDED 
Help Catalogs Search Order List Minimize Clear Prev Next Exit 

APPENDIX VIII 



RICREQI1 



FISHER SCIENTIFIC RIM5 
REQUISITION MANAGEMENT SCREEN 



DATE: 07-29-94 
TIME: 14:54:22 



ACCT NBR: 363690 006 REQ NBR: PO NBR 001 
COMP: 1 REL NBR: 



) UNE 


STOCK NBR 


QTY 


UM 


PT STKRM XREF SPI 


UNIT PRICE 


EXT PRICE 


001 


A191 


1 


EA 


03 






0.00 


0.00 


DESC: 








QTY AVAIL: 


0 


LOC: 


FSHR WHSE: EDC 


002 


02540 K 


1 


PK 


01 






0.00 


0.00 


DESC: 








QTY AVAIL: 


49 


LOC: 


WHSE: JIT 




003 


13246818F 


1 


EA 


03 






0.00 


0.00 


DESC: 








QTY AVAIL: 


0 


LOC: 


FSHR 


WHSE: EDC 


004 


A181-06 


1 


EA 


06 






100.00 


100.00 


DESC: 


ACETONE 






QTY AVAIL: 


0 


LOC: 


WHSE: JIT 





JIT BACKORDER WILL OCCUR 
005 
DESC: 

RESPONSE: KEYS(S): 
I ITEM(S) PROCESSED 



QTY AVAIL: 



LOC: WHSE: 
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-continued 



+F3: EXIT F6: SOURCE F7: BKWD: F8: FWD F9: NEW tTM F10: NONCAT 
Fll: CATALOG F12: CNCL 



IB V123 



APPENDIX IX 



RICPOMP1 



COMP ID: 001 
ACCT NBR: 363690 006 
ORDER NBR: 



FISHER SCIENTIFIC RIMS 
RE QUISITION MANAGEMENT SCREEN 

REQ-NBR: PO NBR 001 
REL-NBR: 

PICKUST REVIEWED: 



DATE: 08-03-94 
TIME: 07:44:13 



SERVICE: 


0.00 ORDER: 


0.00 


FREIGHT: 










CARRIER: 
















OLINE 


PART OTY UOM 


PRD 


UNIT PRICE 


SERVICE EXT PRICE 


LOC 


STAT 


001 


A181 1 EA 


03 


35.30 


0.00 


35.30 


DEL 


S 




ACETONE CERTIFIED ACS 


1L 


QTY AVAIL: 


1 


QTY REC; 0 






002 


02540K 1 PK 


01 


32.70 


0.00 


32.70 


JIT 


S 




BEAKER GRIFFIN 250 ML 


12/9 


QTY AVAIL: 


49 


QTY REC: 0 






003 


13246818F 1 EA 


03 


3495.00 


0.00 


3495.00 


EDC 


S 




PROGRAMMABLE OVEN 




QTY AVAIL: 


0 


QTY REC: 0 






004 


A181-06 1 EA 


06 


100.00 


0.00 


100.00 


JIT 


S 




ACETONE 




QTY AVAIL: 


0 


OTY REC: 0 







RESPONSE: KEY(S): 

+F3:EXIT F6: ACCEPT F7: BKWD F8: FWD F9: PRINT ACK Fll: M/B ERRORS Fl 2 DELETE 
1BV123 



APPENDIX X 



ACCT NBR: 218848 002 
COMP: 001 



*»* REQUISITION MANAGEMENT SCREEN «** 

REQ NBR: TEST NEW ONE 
REL NBR: 

ELECTRONIC SOURCING MESSAGES 

LINE NUMBER 001 
PART ADDED SUCCESSFULLY 

LINE NUMBER 001 
REPLACEMENT WAS MADE FOR PRIOR PART: S100-06 

LINE NUMBER 001 
VENDOR CHANGED FROM: VN00000001 

LINE NUMBER 002 
PART ADDED SUCCESSFULLY 

LINE NUMBER 003 PART NUMBER 53650 

PART ADDED SUCCESSFULLY 

F6: RETURN F7: BACKWARD F8: FORWARD 



PART NUMBER 53610 
PART NUMBER 53610 
PART NUMBER 53610 
PART NUMBER 53620 



We claim: 

1. An electronic sourcing system comprising: 

a collection of catalogs of items stored in an electronic 
format; 45 

a first set of pre-determined criteria associated with said 
collection of catalogs; 

a second set of pre-determined criteria associated with 
items from each of said catalogs; 

a catalog selection protocol, said catalog selection proto- 50 
col relying on said first set of pre-determined criteria to 
select less than said entire collection of catalogs, and 
including matching a vendor identification code with a 
subset of said collection of catalogs, wherein said 
subset of catalogs includes both a vendor catalog from 55 
a predetermined vendor and a second catalog from a 
predetermined third party that is one of a manufacturer 
and a competing vendor, said predetermined third party 
selling items corresponding to items in said vendor 
catalog; and 60 

a search program, said search program relying on said 
second set of criteria to select specific items from said 
catalogs determined from said catalog selection proto- 
col. 

2. An electronic sourcing system as recited in claim 1, 65 
wherein catalogs comprising said collection of catalogs are 
stored in separate databases. 



3. An electronic sourcing system as recited in claim 1, 
wherein said catalogs comprising said collection of catalogs 
are stored in a single database. 

4. An electronic sourcing system as recited in claim 1, 
wherein said predetermined third party makes items in said 
vendor catalog. 

5. An electronic sourcing system as recited in claim l f 
further including a cross reference table linking a vendor 
item catalog number from said vendor catalog with an item 
catalog number from said predetermined third parly. 

6. An electronic sourcing system as recited in claim 1, 
wherein said second set of predetermined criteria includes at 
least one of a catalog number and item textual information. 

7. An electronic sourcing system as recited in claim 1, 
wherein said catalog selection protocol includes providing 
an electronic listing of available catalogs from said collec- 
tion of catalogs. 

8. An electronic sourcing system as recited in claim 7, 
wherein said electronic listing of available catalogs is less 
than said collection of catalogs. 

9. An electronic sourcing system comprising: 

a collection of catalogs of items stored in an electronic 
format; 

a first identification code associated with a first item in a 
first catalog; 

a second identification code associated with a second item 
in a second catalog, said first item and said second item 



50 



55 
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being generally equivalent, and wherein a selection of 
one identification code from one of said first and 
second catalogs provides the other identification code 
from the other of said catalogs. 

10. An electronic sourcing system as recited in claim 9, 
wherein said first identification code is identical to said 
second identification code. 

11. An electronic sourcing system as recited in claim 9, 
wherein at least of one of said first and second catalogs 
includes said first and second identification codes. 

12. An electronic sourcing system as recited in claim 9, 
wherein said selection includes a comparison of said one of 
said first zv<l second identification codes with a cross- 
reference tabl* listing both of said identification codes as 
being generally equivalent. 

13. An electronic sourcing system as recited in claim 9, 
wherein a user selects one of said first and second identifi- 
cation codes, lacks access to said catalog corresponding to 
said selected identification code, but is given access to the 
other said catalog corresponding to said non-selected iden- 
tification code. 

14. An electronic sourcing system as recited in claim 9, 
wherein a user selects one of said first and second identifi- 
cation codes, and has access to both said first and second 
catalogs. 

15. An electronic sourcing system as recited in claim 9, 
wherein said first and second identification codes correspond 
to a part number. 

16. An electronic sourcing system comprising: 

at least two product catalogs containing data relating to 
items such that an item in a first catalog is generally 
equivalent with an item in a second catalog; and 

converting means for converting data relating to said item 
from said first catalog to data relating to said item from 
said second catalog. 

17. An electronic sourcing system as recited in claim 16, 
wherein at least one catalog database contains said data from 
each of said catalogs, and said converting means includes a 
non-catalog database containing a cross-reference table such 
that use of a reference code corresponding to an entry in said 
cross-reference table links said item from said first catalog 
to data relating to said item from said second catalog. 

18. An electronic sourcing system as recited in claim 16, 
wherein one or more catalog databases contain said data 
from each of said catalogs, and said converting means 
including one or more catalog databases including an iden- 
tical reference code corresponding to said data from said 
first catalog and said data from said second catalog. 

19. An electronic sourcing system as recited in claim 16, 
wherein said first catalog may be searched separately from 
said second catalog. 

20. An electronic sourcing system as recited in claim 19, 
wherein a user lacks access to said first catalog and has 
access to said second catalog, such that a request for an item 
in said first catalog provides said data from said second 
catalog. 

21. An electronic sourcing system comprising: 

a requisition module including data fields, user-generated 
criteria entered into at least one of said data fields to 
generate at least partial criteria corresponding to a 
desired item; 

a catalog collection searching module, said searching 
module including a collection of catalogs of items 
stored in an electronic format, a catalog selection 
criteria used to select less than said entire collection, 
said searching module being used to generate addi- 
tional search-module criteria for said data fields of said 
requisition module; 



10 



20 



25 



40 



45 



50 
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60 



65 



a multiple purchase order generation module, said pur- 
chase order generation module creating multiple pur- 
chase orders from a single requisition created with said 
user- generated criteria and said search-module criteria; 

wherein each of at least two catalogs include a generally 
equivalent item from a different source, said requisition 
module working in combination with said catalog 

searching module to determine multiple sources for 

said item; 

wherein said multiple sources is limited by said catalog 
searching module providing a match according to said 
user-generated criteria, said search-module criteria and 
a determination system that located items are generally 
equivalent; and 

wherein said determination system includes a cross ref- 
erence table matching an identification code from a first 
located item with a second identification code from a 
second located item, 

22. An electronic sourcing system as recited in claim 21, 
wherein said determination system includes an identical 
identification code for each of said located items. 

23. An electronic sourcing system, as recited in claim 21, 
wherein said requisition module generates a preferred req- 
uisition based on at least one of product availability and user 
preferences in accordance with a determination of multiple 
sources for a desired item. 

24. An electronic sourcing system as recited in claim 21, 
wherein less than said catalog selection criteria is deter- 
mined by at least one of said user-generated criteria or user 
characteristics. 

25. An electronic sourcing system as recited in claim 24, 
wherein said user characteristics include a listing of catalogs 
from which a user is allowed to purchase. 

26. An electronic sourcing module as recited in claim 21, 
wherein said requisition module uses at least one pre- 
determined rule to select which of multiple sources to use for 
said desired item. 

27. An electronic sourcing system as recited in claim 26, 
wherein said pre -determined rule relies on item availability. 

28. An electronic sourcing system as recited in claim 26, 
wherein said pre-determined rule relies on a hierarchy of 
preferred sources. 

29. An electronic sourcing system comprising: 

a collection of catalogs of items stored in an electronic 
format; 

a first set of pre-determined criteria associated with said 
collection of catalogs; 

a second set of pre-determined criteria associated with 
items from each of said catalogs; 

a catalog selection protocol, said catalog selection proto- 
col relying on said first set of pre-determined criteria to 
select less than said entire collection of catalogs, and 
including matching a vendor identification code with a 
subset of said collection of catalogs, wherein said 
subset of catalogs includes both a vendor catalog from 
a predetermined vendor and a second catalog from a 
predetermined third party; 

a search program, said search program relying on said 
second set of criteria to select specific items from said 
catalogs determined from said catalog selection proto- 
col; and 

a cross-reference table linking a vendor item catalog 
number from said vendor catalog with an item catalog 
number from said predetermined third party. 
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[57] ABSTRACT 

A computer based product catalog system is provided for 
automatically distributing product information to members 
of a network. Electronically stored catalogs of multiple 
manufacturers' products, including descriptions of the 
products, are provided. An electronically stored distributor 
catalog, including selected products from the various manu- 
facturers is also provided. Descriptions of the products in the 
manufacturers* catalogs may be updated automatically. In 
response to the updating of the manufacturers' catalogs, the 
descriptions of the products in the distributor's catalog may 
be automatically updated in real time. A terminal located at 
the retail level of distribution may be operatively connected 
to the manufacturers' catalogs and to the distributor catalog 
to allow viewing of product information therewithin. The 
terminal may enable users to order products from a manu- 
facturer's and distributor's catalog. 
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SYSTEMS AND METHODS FOR 
FACILITATING THE EXCHANGE OF 
INFORMATION BETWEEN SEPARATE 
BUSINESS ENTITIES 

CROSS REFERENCE TO RELATED 
APPLICATION 

This application is a divisional of application Ser. No. 
08/775,276, filed Dec. 31, 1996, now U.S. Pat, No. 5,923, 
552. 

FIELD OF THE INVENTION 

The present invention relates generally to electronic com- 
munications and more particularly to electronic communi- 
cations via computer networks. 

BACKGROUND OF THE INVENTION 

Electronic communications via computer networks are 
replacing traditional modes of communication including 
printed media and voice communication. One form of com- 
puter network communication, known as Electronic Data 
Interchange (EDI), is becoming a standard format for 
exchanging information within a business. However, the use 
of network communications such as EDI as a means for 
communicating between separate business entities has not 
received widespread acceptance because of the independent 
nature of the computer networks of separate business enti- 
ties. 

Computer networks have also been used within a business 
to implement various quantitative analysis techniques such 
as Critical Path Method (CPM) scheduling, Project Evalu- 
ation and Review Technique (PERT) and Material Require- 
ment Planning (MRP). These tools are used to increase the 
efficiency of business operations and to coordinate work 
flow within a business. For example, U.S. Pat. No. 5,233, 
533 to Edstrom et al. describes scheduling software for 
optimizing the scheduling of resources in a factory setting. 
U.S. Pat. No. 4,937,743 to Rassman et al., describes a 
method for the dynamic management of a project involving 
multiple interrelated resources, such as the use of facilities 
and equipment within a business entity. Unfortunately, the 
independent nature of many computer networks and the 
programs designed to run on these computer systems, has 
made the coordination of schedules between separate busi- 
ness entities difficult. Consequently, computer systems have 
often not been used to facilitate the scheduling of interre- 
lated operations of individual business entities across an 
entire industry. 

Product information is often transmitted by manufacturers 
to distributors in an electronic format. Because product 
distributors typically sell products from multiple 
manufacturers, each distributor typically develops its own 
catalog of products using the information provided by the 
various manufacturers. As a result, updated product infor- 
mation received from a manufacturer is not easily or 
promptly forwarded to retailers and others who purchase 
products from distributors because the distributor must 
update its catalog. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to 
facilitate communication and information exchange between 
independent business entities. 

It is another object of the present invention to facilitate the 
coordination of schedules of individual business entities 
within an industry. 



5,641 

2 

It is another object of the present invention to facilitate 
prompt dissemination of product information from manu- 
facturers to oihers downstream in the distribution chain. 
The present invention includes systems, methods, and 

5 computer program products for synchronizing fabrication 
schedules and supplier schedules. A fabrication schedule 
includes a plurality of sequential work stages which are 
stored on a fabricator data processing system. Supplier 
schedules include a plurality of schedules for the sequential 

1Q work stages within a fabrication schedule. Supplier sched- 
ules may be stored on supplier data processing systems. A 
fabrication schedule is obtained from a fabricator data 
processing system, and supplier schedules are obtained from 
respective supplier data processing systems. Restrictive 
links are established between the fabrication schedule and 

1S the supplier schedules. Each restrictive link defines the 
supplier that will perform a work stage, and may also define 
the starting and ending times for both fabrication and 
supplier schedules. 

2Q When a change in at least one of the sequential work 
stages is obtained from the fabricator or from the selected 
one of the suppliers, the restrictive links are automatically 
modified in response to the obtained change. The modified 
fabrication schedule and/or the modified supplier schedule is 

25 communicated to the fabricator data processing system or to 
the supplier data processing system. If a restrictive link 
cannot be modified in response to an obtained change, an 
error message may be returned. Furthermore, if a supplier is 
not able to supply a particular work stage, a second supplier 

30 may be automatically selected. 

The present invention facilitates synchronizing relevant 
portions of a product fabricator's schedules with the various 
schedules of suppliers of materials, labor, and the like. The 
present invention also facilitates the synchronization of 

3S accounting and billing systems, access to product-related 
information, access to legislative and regulatory 
information, and access to on-line catalogs and ordering 
systems for various materials. 
According to another aspect of the present invention, a 

40 scheduling method is provided for reducing the time to 
complete a critical path schedule when completion of at least 
one of the activities in the critical path is delayed. A schedule 
having interrelated activities forming a critical path is stored 
in a data processing system. A float time preceding a selected 

45 activity starting time is assigned and utilized to absorb 
delays in completing activities preceding the selected activ- 
ity. A revised schedule may be generated in the data pro- 
cessing system based upon the absorbed delays. Float time 
may be assigned to multiple selected activities. 

50 According to another aspect of the present invention, a 
computer based product catalog system is provided for 
automatically distributing product information. Electroni- 
cally stored catalogs of multiple manufacturers* products, 
including descriptions of the products, are provided. An 

55 electronically stored distributor catalog, including selected 
products from the various manufacturers is also provided. 
Descriptions of the products in the manufacturers' catalogs 
may be updated automatically. In response to the updating of 
the manufacturers' catalogs, the descriptions of the products 

60 in the distributor's catalog may be automatically updated. A 
terminal located at the retail level of distribution may be 
operatively connected to the manufacturers' catalogs and to 
the distributor catalog to allow viewing of product informa- 
tion therewithin. The terminal may enable users to order 

65 products from a manufacturer's and distributor's catalog. 
The present invention is advantageous because it facili- 
tates the coordination and flow of information between 
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separate business entities within an industry. In particular, financial institutions, and the like. The present invention also 

schedules of separate business entities can be synchronized facilitates the synchronization of accounting and billing 

to establish efficiencies across the industry. The present systems, access to home building-related information, 

invention enhances the flow of information among busi- access to legislative and regulatory information, and access 

nesses without disrupting the autonomy of each business. 5 10 on-line catalogs and ordering systems for materials, 

Furthermore, the present invention allows information to fixtures, and the like. 

flow between the members of an industry without interfering *™ each individual house being fabricated by a home 

with the established channels of trade and business relation- b *Wf r ; home builder typically will develop a fabrication 

s k' schedule which includes z sequential listing of all activities 

10 or work stages related to the completion and sale of the 

BRIEF DESCRIPTION OF THE DRAWINGS house. For example, work stages may include, but are not 

limited to, grading the lot upon which a house is to be built, 

FIG. 1 illustrates a Network Service Distribution System digging the foundation, pouring the footings upon which the 

and a Calendar-Driven Desktop System for synchronizing house restSj frarning tne structure, placing a roof over the 

schedules and exchanging information between separate framing, covering the framing with sheathing, laying up 

business entities, according to the present invention. brick veneerj and finishing the inside of the house. Each of 

FIGS. 2A, 2B, 2C illustrate the interdependencies of these work stages will typically be assigned starting limes 

multiple projects. and will be sequentially arranged so that the house is built 

FIGS. 3A, 3B illustrate adding preceding float time to in the shortest amount of time. As is known to those having 

various work stages in a CPM schedule, according to the 2 o skil1 in lhc art > some work sta 8 es mav occur substantially 

present invention. ** concurrently, while others require the completion of a pre- 

FIG. 4 schematically illustrates a method of synchroniz- cedin 8 work sta S e before tne V can occur - 

ing a fabrication schedule and a plurality of supplier The home builder will typically enter into a relationship 

schedules, according to the present invention. or contract with another party, such as a sub-contractor or 

FIGS. 5A, 5B, 5C schematically illustrate in greater detail 25 material supplier to perform the work and/or deliver mate- 

a method of synchronizing a fabrication schedule and a nals tor . each of these work f a ^- I* either case the 

plurality of supplier schedules. contticiiijg party is a suppher of either labor or materials or 

™~ , .„ , , both. Each contract between the home builder and a supplier 

FIG. 6 illustrates a computer based product catalog sys- of labor/materiaIs typically includes 

a time of performance 

tern for distributing product information, according to the ^ QQ the paft of the suppUer ^ ^ each ^ 

present invention. restrictively link the supplier's schedule of performance to 

DETAILED DESCRIPTION OF PREFERRED me nome builder's schedule for a particular house. Because 

EMBODIMENTS most su PP^ ers °£ labor/materials are supplying labor/ 

materials for multiple houses and projects, it is important 

The present invention now is described more fully here- 3S that a home builder's schedule for a particular house be 

inafter with reference to the accompanying drawings, in synchronized with a supplier's schedule. In particular, it is 

which preferred embodiments of the invention are shown. important for a home builder to know that if a work stage 

This invention may, however, be embodied in many different starting date is changed for some reason, the supplier 

forms and should not be construed as limited to the embodi- supplying labotfmaterials for that work stage either can or 

ments set forth herein; rather, these embodiments are pro- 40 cannot perform under the contract. If the supplier cannot 

vided so that this disclosure will be thorough and complete, perform because of its schedules related to other projects, 

and will fully convey the scope of the invention to those the home builder must secure a contract with another 

skilled in the art. supplier. 

According to one aspect of the present invention, a An exemplary work stage during the construction of a 
computer network system having a dynamic scheduling 4S house is the framing of the house structure. A home builder 
sys tern for integrating schedules of separate business entities will typically locate a particular supplier (i.e. a framing 
within an industry is disclosed. The present invention leaves crew) to begin and complete the framing work stage within 
the independence and management of individual business a given time period. For example, assume that framing of a 
entities intact, yet allows the whole industry to work as a particular house is slated to take twenty days beginning on 
single, efficient organization. Utilizing the present invention, 50 January 1. The home builder enters into a contract with 
a business entity may view and interact with information of framing crew A to begin framing on January 1 and complete 
other members an entire industry. Each business continues to framing no later than January 21. Typically, the contract or 
compete with other businesses in the industry, yet schedul- restrictive link between the home builder and framing crew 
ing of activities, project management and exchange of A will include some reasonable time range in which the 
information necessary for the whole industry to function can 55 starting date of framing can vary, such as plus or minus three 
become organized and efficient via the present electronic days. Thus, if the foundation work, which must be corn- 
computer network system. To facilitate scheduling and pleted prior to framing, is not completed until January 2, the 
project management across an entire industry, the present home builder knows that framing crew A can still perform, 
invention utilizes and enhances known scheduling tech- However, if the foundation work is not completed until 
niques including Critical Path Method (CPM) to allow each 60 January 18, the contract between the home builder and 
network member to maintain individual schedules yet syn- framing crew Ais no longer valid and the home builder must 
chronize relevant portions of these schedules with the sched- either ask framing crew A if it can still perform, or the home 
ules of other industry members. builder must look for another framing crew. 

Using the home building industry as an illustrative The above scenario is often repeated in the home building 

example, the present invention facilitates synchronizing 65 industry and other fabrication industries many times during 

relevant portions of a home builder's schedules with the a single project. The home builder or other product fabri- 

various schedules of vendors, suppliers, manufacturers, cator typically spends a lot of time securing contracts with 
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suppliers of labor/materials, both at the beginning of a about network members. The term "network members" shall 

fabrication schedule and throughout the schedule as the mean business entities within an industry that have access to 

starting and ending limes of the various work stages are the computer network system 10 illustrated in FIG. 1, or a 

changed. The present invention facilitates establishing con- computer network system capable of carrying out the meth- 

tracts or restrictive links between product fabricators, such 5 oc k 0 f the present invention. It is contemplated by the 

as home builders, and suppliers of labor and/or materials. present invention that each network member is a distinct and 

The present invention also facilitates the automatic synchro- separate business entity within a particular industry. The 

nization of a fabricator's schedule for a particular project or Member Services Subsystem 22 preferably maintains the list 

product with the schedules of many suppliers of labor and/or of network members and validates the identity of a user in 

materials as changes occur to either the fabricator's schedule 1Q communication with lhe Network Service Distribution Sys- 

or a supplier's schedule or both. The present invention afco tem20 . The BiUing Services Subsystem 24 preferably tracks 

facilitates residing a contract be wee n a fab nca tor and * ^tribution System 20 for 

supplier when the rescinded contract does not permit a * , ..... . / ,. . 

particular change to either the fabrication schedule or the ««* netwo * mem ^ r ^ 8™ rates billing information for 
supplier's schedule, and facilitates the establishment of a each network member - ™ e Messaging Services Subsystem 
replacement contract between the fabricator and another » 26 is used to store and forward electronic mail and other 
supplier. The present invention may be utilized in a variety asynchronous message types between network members, 
of industries and is not limited to the home building industry. Preferably, various publications and discussion forums are 
A preferred computer network system for carrying out accessible by network members via the Messaging Services 
methods of synchronizing a fabrication schedule with a Subsystem 26. Also, gateways are preferably provided to the 
plurality of supplier schedules, according to the present 20 Internet and other electronic networks for inter-industry 
invention, is a dynamic system wherein schedule changes information exchange. The Distributed Scheduling Sub- 
made by a network member ripple down to all network system 28, described in greater detail below allows each 
members and are automatically integrated within the sched- network member to integrate its schedules within the sched- 
ule of each respective network member as appropriate. For ules of other network members. 

example, if rain delays the framing of a house, the lumber 25 The Loan Services Subsystem 30 facilitates access to 
yard's delivery schedule will be updated automatically to financial services for network members and their customers, 
deliver lumber on a new date specified in the home builder's Preferably, communication with major financial institutions 
schedule. The present invention permits such changes to be is available via the Loan Service Subsystem 30. The General 
made remotely through the use of various input devices, Transaction Services Subsystem 32 facilitates a store and 
including personal data assistants and other computer ter- 30 forward process for standardized messages that routinely 
minals in communication with a central data processing travel between network members in the course of conduct- 
system, ing commerce. Exemplary messages include standardized 
Referring now to FIG. 1, a computer network system 10 accounting messages and standardized project management 
for synchronizing schedules and facilitating the flow of messages. Preferably, all messages passing through are 
information between multiple business entities within an 35 stored for audit trail purposes. The Distributed Product Data 
industry, according to a preferred embodiment of the present Management Subsystem 34 makes available electronically 
invention, is illustrated. In the illustrated embodiment, the recorded product information to distributors, retailers, and 
computer network system 10 includes a centrally-located consumers. The Consumer Product or Service Marketing 
Network Service Distribution System 20 and a plurality of Subsystem (not shown) connects network members with 
Calendar-Driven Desktop Systems 60, each in communica- 40 consumers and facilitates "on-line" shopping, 
tion with the Network Service Distribution System. Each The Network Service Distribution System 20 and its 
Calendar-Driven Desktop System 60 is the user interface illustrated subsystems may serve as a means for: obtaining 
members of the computer network system 10 use to com- a fabrication schedule from a fabricator's data processing 
municate and exchange information with other network system; obtaining supplier schedules from respective sup- 
members via the Network Service Distribution System 20. 45 p ij er <j ata processing systems; automatically selecting a 
The Network Service Distribution System 20 and each supplier from a plurality of suppliers; and communicating a 
Calendar-Driven Desktop System 60 contain subsystems selection to the supplier system which corresponds to the 
that are described in detail below. selected supplier. The Network Service Distribution System 

Network Service Distribution System Cft 20 ma y also include a fabricator data processing system for 

. . „ 50 storing fabrication schedules which include multiple work 

The Network Serv,ce Distribution System 20 contains the st afra d j,^,^ ^ Network Service Distn . 
following subsystems that may apply generally to any bu|ion s , em w abo inc|ude , luraIj , of , ier 
mdustry: Member Services Subsystem 22, Billing Serv.ces dala processing systems for storing a ^dub for each 
Subsystem 24, Messaging Services Subsystem 26. Dislnb- sequemial work stage pe r f orine d by a particular supplier, 

uted Scheduling Subsystem 28, Loan Services Subsystem 55 

30, General Transaction Services Subsystem 32, Distributed Calendar-Driven Desktop System 

Product Data Management Subsystem 34, and a Consumer The Calendar-Driven Desktop System 60 provides the 
Product or Service Marketing Subsystem (not shown). network interface for communications with the Network 
These subsystems can be categorized as general services, as Service Distribution System 20 and with other network 

illustrated, because they are typically useful and important 60 members. It also provides users with a calendar of tasks and 
to any industry. In addition, one or more, industry-specific work stages needed for carrying out the operations of a 
subsystems 40 can be added as necessary. Industry-specific network member's business. Standardized messages from 
subsystems 40 can be categorized as extended services, as the General Transaction Services Subsystem 32 can auto- 
illustrated, because they are typically unique to a particular matically produce intelligent calendar entries. These calen- 

uidustry. 6 5 d ar entries may be employed to launch applications when 
The Member Services Subsystem 22 and the Billing selected, or they can automatically launch on a given date. 
Services Subsystem 24 are used to maintain information Calendar entries can likewise be used to send standardized 
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messages back to the General Transaction Services Sub- with the Network Service Distribution System 20 for work 
system or can send them automatically 32. activity calendar schedules. The Integrated Project Manage- 
Using the home building industry as an example, when it ment system 66 and the Integrated Work Activity Calendar 
is time to order supplies for a given work stage of a project, 64 can both generate bid requests to other network members 
a calendar entry created by a project management or project 5 via the General Transaction Services Subsystem 32 for the 
planning application can automatically place the order. Cal- purpose of establishing contracts between network mem- 
endar entries can also automatically confirm that an order bers. If bid requests are accepted, contracts can be estab- 
will be delivered on time. Recurring calendar entries can be lished using the General Transaction Services Subsystem 32. 
used to launch recurring applications or functions appropri- Once a contract is established, the Distributed Scheduling 
ate for a network member's business. Calendar entries may 10 Subsystem 28 may serve as a means for establishing restric- 
be used to integrate project management, integrate work tive links between the schedules of the contracting parties, 
activity calendars, and integrate accounting. For project Network members may utilize the Calendar-Division Desk- 
management, calendar entries can issue purchase orders and l0 P t s y stem 60 00 an ongoing basis to monitor and update 
bid requests, or ask for confirmation regarding material work progress on particular projects. When network mem- 
deliver}. For accounting, calendar entries can be used to 15 bers indicate that a work stage or task is complete the 
. *. . • * i_ 1* u restrictive link may be removed by the Distributed Sched- 
send and receive invoices. Any subsystem application can be Subs ^ cm 28 

written under the Calendar-Driven Desktop System 60 to U ^ » J* ^ Accounting Subsystem 62 is preferably 

provide . hai particular application w.th industry-wide com- int tcd * with jcct ma 8 Qagcrac y nt and work F activity y 

munition through the Network Service Distribution Sys- sch * du[cs of a ne f W0 J rk mcm beFsuch that accounting infor- 

tem 20 utilizing a standardized application programming 20 malion is automatically oblained without rc dundant data 

interface (API). entry Distributed scheduling and project management, 

In the illustrated embodiment of FIG. 1, the Calendar- a i on g with the General Transaction Services Subsystem 32, 

Driven Desktop System 60 includes the following: Inte- allows the Integrated Accounting Subsystem 62 of the 

grated Accounting Subsystem 62, Integrated Work Activity Calendar-Driven Desktop System 60 to function with little 

Calendar 64, and Integrated Project Management Subsystem 2 s or no data entry. Accordingly, the majority of normal func- 

66. The Calendar-Driven Desktop System 60 receives and tions required for bookkeeping, such as invoice entry, may 

sends messages between network members and the various be eliminated. 

subsystems within the Network Service Distribution System The Integrated Work Activity Calendar Subsystem 64 is 
20. Each message is received and distributed within the used by suppliers who enter into contracts with other net- 
Calendar-Driven Desktop 60 according to the subsystem or 30 work members to supply labor and/or materials for a work 
program application most appropriate to its purpose. For stage of a fabrication schedule. The Integrated Work Activity 
example, messages from the General Transaction Services Calendar Subsystem 64 facilitates receiving bid requests for 
Subsystem 32 arrive as stages of work or tasks linked io the the supply of labor and/or materials from network members 
Integrated Accounting Subsystem 62. These messages and is designed to automatically accept or reject bid 
appear as calendar entries requiring attention by a network 3S requests, depending on the nature of the bid requests and 
member. Preferably, calendar entries are automatically also depending on the availability of time in a network 
entered and adjusted by the Integrated Accounting Sub- member's schedule. Advantageously, since schedules are 
system 62 and Integrated Project Management Subsystem maintained by the Distributed Scheduling Subsystem 28, a 
66. Calendar entries or messages from the General Trans- network member does not have to be in continuous corn- 
action Services Subsystem 32 may automatically launch 40 munication with the computer network system 10. A net- 
appropriate applications associated with completing or work member can, instead, periodically dial-in and connect 
resolving the specific type of standardized message. to the Network Service Distribution System 20 using a 
The Calendar-Driven Desktop System 60, and its illus- personal computer and modem, including a small portable 
trated subsystems, may serve as a means for: obtaining a computer with a cellular modem. 

fabrication schedule from a fabricator's data processing 45 The Integrated Work Activity Calendar Subsystem 64 

system; obtaining supplier schedules from respective sup- may serve as a means for obtaining fabrication schedules 

plier data processing systems; automatically selecting a and supplier schedules from the Distributed Scheduling 

supplier from a plurality of suppliers; and communicating a Subsystem 28. If changes are made to a schedule, the 

selection to the supplier system which corresponds to the Distributed Scheduling Subsystem 28 may serve as a means 

selected supplier. The Calendar-Driven Desktop System 60 50 for obtaining the change and for automatically modifying a 

may also include a fabricator data processing system for restrictive link associated with the change. If the restrictive 

storing fabrication schedules which include multiple work link may not be modified because of schedule conflicts or for 

stages arranged sequentially. The Calendar-Driven Desktop other reasons, an error message is returned. A network 

System 60 may also include a plurality of supplier data member has the option of canceling a contract with another 

processing systems for storing a schedule for each sequential 55 network member, which deletes any restrictive links asso- 

work stage performed by a particular supplier. dated with the contract and sends a message to the affected 

The Integrated Project Management Subsystem 66 is a network members, via the General Transaction Services 

network member's interface with the Network Service Dis- Subsystem 32, indicating that a contract has been canceled, 

tribulion System 20 for fabrication and supplier project When an Integrated Project Management Subsystem 66 

schedules, such as CPM schedules. Using the home building 60 receives such a message it attempts to automatically handle 

industry as an example, a home builder may use the Inte- the scheduling conflict. It issues bid requests to try and 

grated Project Management Subsystem 66 to obtain, modify, reestablish the contract with the same network member at a 

and communicate to suppliers its fabrication schedule. different time. If this fails within the preceding float range 

Similarly, each supplier of labor and/or materials may use allowed for the conflicted work stage, the Integrated Project 

the Integrated Project Management Subsystem 66 to obtain, 65 Management Subsystem 66 then issues bid requests to other 

modify, and communicate its schedules. The Integrated network members. Unresolved scheduling conflicts prefer- 

Work Activity Calendar 64 is a network member's interface ably generate notifications to affected network members. 



03/26/2003, EAST Version: 1.03.0002 



6,i: 

9 

Schedule Synchronization Between Network 
Members 

Typically each member of the computer network system 
10 is a separate business entity within an industry and has 
one or more work schedules. Generally, there are two types 
of work schedules: CPM schedules, and work activity cal- 
endar schedules. A work activity calendar schedule is simply 
a schedule of appointments. It is simitar like the notebook of 
scheduled activities that a businessman maintains. A CPM 
schedule is a sequential arrangement of work stages, some 
of which may not begin until previous ones have been 
completed. Individual tasks can be work stages in both types 
of schedules. Restrictive links can be established between 
either of these two types of schedules. Work stages within a 
schedule may have restrictions placed on them by their 
owners to indicate how far the starting and ending times of 
the work stage can vary. 

A work stage is a step in the fabrication of a product and 
has a time duration defined by a starting time and an ending 
time. As used herein, the terms "time(s)" and **date(s)" shall 
have the same meaning and shall be interchangeable. Sched- 
ules can be at different scales, with more detailed schedules 
inside of lesser detailed schedules. For example: a schedule 
of new office construction in a business park— office one 
must be completed before office two can begin, and so forth. 
Each office project can have a detailed schedule of events 
required to complete its construction. Thus, the detailed 
schedule is a "child" of the lesser detailed "parent." 
Preferably, work stages cannot be linked to work stages 
shared between parent and child projects. For example, if 
work stage A is part of a project which is contained in work 
stage B, then no work stage that is in the same project as 
work stage B may be linked to work stage A, as this would 
cause a circular dependency. With this restriction in place, 
the system can allow for entire projects within a single work 
stage. 

In the illustrated embodiment, the Distributed Scheduling 
Subsystem 26 automatically updates interrelated schedules 
of network members and allows each network member to 
make changes to its schedules in consideration of up-to-date 
knowledge about the status of the schedules of other net- 
work members. Preferably, the Distributed Scheduling Sub- 
system 26 utilizes enhanced CPM scheduling techniques 
which permit restrictions and relationships to be established 
between a broad range of work stages and project scales, 
each able to be restricted by the other, regardless of the scale 
of a stage of work. For example, a set of work stages that 
define a project can be considered as a single work stage that 
is related to or restricted by, one or more other work stages, 
jobs, large-scale projects, and the like. Similarly, a collection 
of jobs that make up a large scale project may be considered 
a single work stage that is related to or restricted by a work 
stage, a job, a large-scale project, and the like. Preferably, 
the Distributed Scheduling Subsystem 28 stores the various 
fabrication and supplier schedules of network members 
within one or more databases. 

Referring now to FIG. 4, a method of synchronizing a 
fabrication schedule and a plurality of supplier schedules, 
according to the present invention, is illustrated. Steps 
include: obtaining a fabrication schedule from a fabricator 
data processing system (Block 100); obtaining supplier 
schedules from respective supplier data processing systems 
(Block 102); establishing restrictive links among a fabrica- 
tion schedule and supplier schedules (Block 104); obtaining 
a change in a fabrication schedule work stage (Block 106); 
automatically modifying restrictive links in response to an 
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obtained change (Block 108); and communicating a modi- 
fied fabrication or supplier schedule to a fabricator data 
processing system or to a supplier data processing system 
(Block 110). 

5 The illustrated method is preferably recursive such that it 
calls itself for the purpose of determining whether changes 
are necessary to other schedules of network members when 
a given schedule has a changed time. When the starting time 
of a restrictively linked work stage is changed, and nothing 

10 prevents the work stage on the other end of the restrictive 
link from changing its starting or ending time, the Distrib- 
uted Scheduling Subsystem 28 automatically modifies the 
restrictive link in response to the starting time change. In the 
illustrated embodiment, the Distributed Scheduling Sub- 

15 system 28 handles the process of checking whether work 
stages restrictively linked can be rescheduled. Each restric- 
tive link contains information about the range of time within 
which a work stage starting or ending time can be changed. 
If a work stage cannot be automatically rescheduled, the 

20 changes are not made and a conflict error is returned to 
network members affected by the conflict. 

If scheduling conflicts cannot be resolved by 
rescheduling, the present invention is designed to attempt to 
reschedule with another network member from a pre- 

25 determined list of alternates. For example, if a home build- 
er's fabrication schedule has a work stage for framing with 
a starting time that has slipped such that a restrictively linked 
framing crew A cannot perform the work, the present 
invention will attempt to establish a contract between the 

30 home builder and another framing crew on that home 
builder's list of approved framing crews. The present inven- 
tion may attempt to resolve scheduling conflicts by delaying 
the starting times of restrictively linked schedules. If this is 
unsuccessful, alternative resolutions may be pursued. 

35 FIGS. 5A, 5B, 5C are flow diagrams, illustrating a recur- 
sive method of synchronizing a fabrication schedule and a 
plurality of supplier schedules, according to one embodi- 
ment of the present invention, when a change is made to the 
fabrication schedule. To make modifications to an existing 

40 fabrication schedule, a network member (fabricator) "checks 
out" or obtains a copy of the fabrication schedule from the 
Distributed Scheduling Subsystem 28, makes the changes to 
the fabrication schedule, and attempts to synchronize the 
modified fabrication schedule with other supplier schedules. 

45 Referring now to FIG. 5A, for each fabrication schedule 
stored (or to be stored) within the Distributed Scheduling 
Subsystem 28, a CPM calculation method is performed to 
generate starting and ending dates of all work stages within 
the fabrication schedule (Block 122). This may be per- 

50 formed either locally via a Calendar-Driven Desktop System 
60, or centrally via a Network Service Distribution System 
20. For existing fabrication schedules that are being checked 
into the Distributed Scheduling Subsystem 28, a copy of the 
fabrication schedule, as it existed when it was checked out 

55 from the Distributed Scheduling Subsystem, is obtained 
(Block 124). 

When a modified or new fabrication schedule is checked - 
in with the Distributed Scheduling Subsystem 28, the pre- 
existing starling and ending times of all work stages are 

60 compared with those of the fabrication schedule to identify 
any changes. This is illustrated as an iterative loop (Block 
126-Block 130) in FIG. 5A. If any work stage starting times 
are changed, several steps are then performed. First, a work 
stage having a changed starting or ending time is checked to 

65 see if a lower level fabrication schedule is contained within 
the work stage with the changed starting or ending times 
(Block 132). If there is a lower level fabrication schedule 
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associated with a work stage having changed starting or determination is made whether this is the first recursive call 

ending limes, then the lower-level fabrication schedule is lo check-in (Block 170). If the answer is yes, the temporary 

recursively checked-out (Block 134). If the overall starting table is stored within the fabrication schedule database and 

time (i.e., the starling time of the first work stage in the all schedules are indicated as checked-in (Block 172). If the 

schedule) of the lower-level fabrication schedule has been 5 answer is no, a message of successful check-in is returned 

changed, a CPM calculation is performed to generate new (Block 174). 

starting and ending times for each work stage (Block 136) The above-described recursive procedure is applicable to 

within the lower-level fabrication schedule. The lower- level all schedules, including fabrication and supplier, that are 

fabrication schedule is then recursively checked back in changed and which are restrictively linked with other sched - 

(Block 138). The recursive check-in allows for a continuous Q ules. The present invention preferably includes additional 

comparison of work stage starting times with original start- features such as when a threshold amount of computer 

ing times. Next, a determination is made whether the lower- storage space is exceeded by changed schedules. If such a 

level fabrication schedule has been successfully checked in threshold is exceeded, an error message is produced, 

without any errors (Block 140). If the answer is yes, the Additionally, if an attempt is made to check-out a schedule 

procedure proceeds to Block 142, otherwise, the procedure 15 that is already waiting to be updated by the same recursive 

proceeds to Block 164. procedure, an error message is returned. If an attempt is 

Referring now to FIG. 5B, after lower-level fabrication made to check-out a schedule that is waiting to be updated 

schedules have been modified and recursively checked, by another recursive procedure, the system wails until that 

where necessary, a fabrication schedule work stage having a recursive procedure is completed. 

changed starting or ending time is checked for a restrictive 20 It will be understood by those having skill in the art that 

link with a supplier schedule (Block 142). If no restrictive one or more of the steps set forth in the flow charts of FIGS, 

link exists for the changed work stage, the procedure con- 4 and 5 A, 5B, 5C may be implemented using computer 

tinues in an iterative loop to the next work stage having a readable program code, embodied within computer usable 

changed starting or ending time and checks for any restric- media, executing on a general purpose computing system, 

tive links thereto (Block 144). If no restrictive links are 25 on a special purpose computing system, or on a combination 

found for any work stages having changed starting or ending thereof. It will also be understood that, for the flow charts set 

times, the procedure terminates, and the fabrication schedule forth in FIGS. 4 and 5A, 5B, 5C, each block, and combi- 

is checked in. When no restrictive links exist between work nations thereof, may be implemented by computer program 

stages of a fabrication schedule that have been changed and instructions. These computer program instructions may be 

supplier schedules, any changes made to the fabrication 30 loaded into a computer or other programmable apparatus to 

schedule have no impact on the supplier schedules. produce a machine, such that the instructions which execute 

If a fabrication schedule work stage with a changed on the computer or other programmable apparatus create 

starting or ending date is restrictively linked to a supplier means for implementing the functions specified in the flow 

schedule, this supplier schedule is located (Block 146). A chart block or blocks. 

determination is made whether the restrictively linked sup- 35 The computer program instructions may also be stored in 

plier schedule can be changed in accordance with the change computer readable media (including magnetic media, optical 

to the work stage at the other end of the restrictive link media, read only memory, random access memory, and the 

(Block 148). If the supplier schedule can be rescheduled, the like) that can direct a computer or other programmable 

supplier schedule is checked-out by the Distributed Sched- apparatus to function in a particular manner, such that the 

uling Subsystem 28 (Block 152), and the supplier schedule 40 instructions stored in the computer readable media produce 

is changed accordingly (Block 154). If the supplier schedule an article of manufacture including instruction means which 

contains work stages sequentially arranged, a CPM calcu- implement the function specified in a flow chart block or 

lation is performed to generate starting and ending times blocks. The computer program instructions may also be 

(Block 156). The supplier schedule is then recursively loaded into a computer or other programmable apparatus to 

checked-in with the Distributed Scheduling Subsystem 28 45 cause a series of operational steps to be performed on the 

(Block 158). If check-in is successful (Block 160), the computer or other programmable apparatus to produce a 

recursive procedure continues to the next fabrication sched- computer implemented process such that the instructions 

ule work stage with a changed starting or ending time (Block which execute on the computer or other programmable 

162) and the above-described procedure is repeated. If apparatus provide steps for implementing the functions 

check-in is not successful, the procedure proceeds to Block 50 specified in a flow chart block or blocks. 

164. According to another aspect of the illustrated embodiment 

During the recursive procedure described above, if any in FIG. 1, the Integrated Project Management Subsystem 66 
schedule changes are not allowed, a conflict error message may be constantly updated with work progress by network 
is returned to the appropriate subsystem within the affected members. The term "work progress" includes expected work 
network member's Calendar-Driven Desktop System 60 and 55 stage completion times and actual work stage completion 
no schedule changes are made. Database updates for sched- limes. When work progress shows that a work stage ending 
ule check-ins are delayed until the recursive procedure is lime is expected to be delayed, the Integrated Project Man- 
complete. When the procedure is complete, all stored sched- agement Subsystem 66 may check-out the fabrication 
ules are updated. If an unsuccessful check-in of a supplier schedule, update work stage starting and/or ending times 
schedule has occurred (Block 160) or if a restrictive link 60 accordingly, and perform a CPM calculation to generate 
does not allow a supplier schedule to change (Block 148), starting and ending times for all work stages in the fabrica- 
the supplier schedule is marked within a temporary table as lion schedule. The Integrated Project Management Sub- 
checked-in (Block 164) and an error message is returned system 66 may then attempt to check-in the fabrication 
(Block 166). schedule into the Distributed Scheduling Subsystem 28. 

Referring now to FIG. 5C, when the iterative loop defined 65 Depending on the existence of restrictive links, this opera- 

by Block 126-Block 130 is complete, the fabrication sched- tion may succeed or fail. If it fails, the Integrated Project 

ule is stored within a temporary table (Block 168). A Management Subsystem 66 may receive a list of conflicting 
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restrictive links from the Distributed Scheduling Subsystem 
28 which are used to develop solutions to the scheduling 
conflict(s). Depending on the nature of a particular project or 
work stage, the Integrated Project Management Subsystem 
66 may cancel the originally scheduled process or relation- 
ship with a supplier and establish a new one with another 
network member supplier. The Integrated Project Manage- 
ment Subsystem 66 may also force a delay on a work stage 
starting time, re-compute the fabrication schedule, and 
attempt to check-in the fabrication schedule with the Dis- 
tributed Scheduling Subsystem 28. According to one aspect 
of the present invention, the Integrated Project Manager 
Subsystem 66 may be designed to automatically track fab- 
rication and supplier schedules of network members and 
keep them synchronized or find solutions when scheduling 
conflicts arise. 

Home Building Industry Example 1 

In the home building industry, a home builder typically 
has several projects (houses) under construction and others 
that are about to start. Each project has a fabrication sched- 
ule with multiple, sequentially arranged work stages stored 
in a Distributed Scheduling Subsystem 28. As the home 
builder enters into contracts for materials and labor for each 
work stage, restrictive links are established among the 
fabrication schedule and the multiple supplier schedules. 
The process of forming contracts with other network mem- 
ber suppliers is preferably performed via the General Trans- 
action Services Subsystem 32. When a contract is formed 
between the home builder and a supplier, the Integrated 
Project Management Subsystem 66 "checks-out" the home 
builder's fabrication schedule for this project. Preferably, at 
about the same time, the Integrated Work Activity Calendar 
64 for the home builder checks-out the activity calendar for 
the subcontractor/supplier. Both systems (the Integrated 
Project Management Subsystem 66 and Integrated Work 
Activity Calendar 64) indicate that a restrictive link has been 
established between at least one work stage in the fabrica- 
tion schedule and a supplier schedule, per the established 
contract. Both systems (the Integrated Project Management 
Subsystem 66 and Integrated Work Activity Calendar 64) 
check- in the restrictively linked fabrication and supplier 
schedules. Preferably, the Distributed Scheduling Sub- 
system 28 recognizes restrictive link indicators and estab- 
lishes actual restrictive links between the respective sched- 
ules. 

Preferably, work progress is recorded into the Integrated 
Project Management Subsystem 66 which calculates the 
starting and ending times of the fabrication schedule work 
stages using CPM calculation methods. The fabrication 
schedule is checked-in and a changed starting time for a 
work stage is identified. The home builder's Work Activity 
Calendar is contacted to see if the time change can be 
accommodated. If yes, the starting time change is made. If 
no, the check-in fails and an error message is returned to the 
Integrated Project Management Subsystem 66 of the home 
builder. 

Assigning Float Time to Work Stages Within a 
Critical Path Schedule 

A critical path schedule includes a sequential arrangement 
of work stages, some of which cannot be performed until a 
prior one is performed. If a starting time is known for a given 
schedule, the starting and ending times for each work stage 
in the schedule can be computed utilizing various CPM 
calculation methods known to those having skill in the art. 
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A delay to one work stage in a critical path will have a 
cascade effect on the schedule such that for each day a work 
stage is delayed, a delay to the entire schedule results. Work 
stages that are not on the critical path are considered to have 

5 float. A work stage with three days float can exceed its 
scheduled duration by three days without affecting the 
overall schedule. 

Referring now to FIGS. 2A,2B,2C, four different projects 
70a, 706, 70c, 70</, each with three work stages slated to last 

10 one day, are illustrated. Alone, each project should take three 
days to complete; however, some of the work stages must 
await the completion of work stages in other projects. With 
such an interdependency of work stages, a single change to 
a work stage can cause a large sequence of cascade schedule 
5 changes. FIG. 2B clarifies the actual flow of completion for 
each project illustrated in FIG. 2A. Projects 1, 3 and 4 can 
begin on day one, but Project 2 is delayed by a day until the 
completion of work stage 1 in Project 1. Though Project 3 
can start on day one, it has a two day delay before work can 

20 continue as it awaits the completion of work stage 2 for 
Project 2, and so forth. Though requiring the same number 
of days to complete, and even though it began at the same 
time as Project 1, Project 4 requires three extra days to 
complete because of work stage 3 of Project 3. 

25 FIG. 2C illustrates the cascade effect caused to the four 
projects in FIGS. 2A and 2B when a single work stage in one 
of the projects is delayed. Because work stage 3 in Projects 
1 and 2, and work stage 2 in Project 3 are all dependent upon 
the completion of work stage 2 in Project 2, they are each 

30 delayed until work stage 2 in Project 2 is completed. 

According to another aspect of the present invention, the 
Distributed Scheduling Subsystem 28 prevents small sched- 
ule changes to critical path schedules from causing large 
cascading schedule changes. This is accomplished by adding 

35 a quantity of time, referred to as "float time", to the starting 
time of a selected work stage or activity, as illustrated in 
FIGS. 3A and 3B. FIG. 3A illustrates multiple work stages 
84-90 which define a critical path. Work stages 85, 88 
include preceding float time 85a, 88a, respectively, prior to 

40 their starting time. As a result of the preceding float time, 
work stages 85, 88 are not on the critical path that deter- 
mines the minimum length of the schedule. Note that there 
is a two day difference between the start of work stage 88 
with preceding float 88a and work stage 87. 

45 FIG. 3B depicts the effects on the schedule illustrated in 
FIG. 3A as a result of a one day delay to the first work stage 
84. Consistent with CPM scheduling techniques, each work 
stage on the critical path is delayed by one day, causing the 
entire schedule to take one day longer than originally 

50 planned. However, the actual work days scheduled for work 
stage 85 remained the same and the available preceding float 
85a has simply been reduced. The entire cascade potential 
on the subsequent work stage with preceding float time has 
thus been absorbed. As a result, the preceding float time 

55 remains unchanged for work stage 88 even though other 
work stages around it, have been adjusted. Note the two day 
gap between work stages 87 and preceding float 88a (FIG. 
3 A) has been reduced to only 1 day. Utilizing the preceding 
float allowed the fabricator's system to manage the start 

60 times after the delay so that the system did not automatically 
bump the succeeding work stage back an additional day. 
Rather, the system utilized the pre-determined preceding 
float in order to hold the later work stages to their original 
start dates, therefore not all work stages were changed, thus 

65 not all suppliers were affected. 

According to the present invention, if a work stage in the 
critical path has an ending time later than scheduled, pre- 
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ceding float time on following work stages can prevent them 
from being rescheduled. When a work stage starting or 
ending time is modified, the preceding float time is adjusted 
in order lo keep the actual work stage starting time the same. 
Preferably, the preceding float quantity is restricted such that 
it cannot go below zero or above a maximum preceding float 
quantity. 

Automatic Product Information Undating 

Typically, product distributors purchase products from 
product manufacturers and sell them lo retailers and end 
users. When product manufacturers make changes to their 
products, or change information about their products, dis- 
tributors typically accumulate this information and retrans- 
mit it (in printed or electronic form) to retailers and end 
users. The task of collecting and re-transmitting product 
information can be daunting. The present invention, through 
the Network Service Distribution System 20, makes product 
manufacturer information available to all network members 
who need the information without the duplicative efforts of 
distributors. The present invention allows product informa- 
tion to flow directly from manufacturers to retailers, 
distributors, and end users without interfering with the 
established channels of trade and business relationships. 

The present invention, via the Distributed Product Data 
Management Subsystem 34, facilitates the electronic distri- 
bution of product information from network members who 
are product manufacturers to other network members. 
Because network members can view product information 
electronically and because the information is updated by 
manufacturers and automatically distributed down through 
the network, network members who are distributors do not 
have to maintain and redistribute constantly changing manu- 
facturer product information. 

According to one aspect of the present invention, a 
computer based product catalog system is provided. The 
computer based product catalog system includes multiple 
electronically stored manufacturer catalogs which include 
descriptive text, numerical data (measurements), multimedia 
information (video, audio, etc.) describing items manufac- 
tured by respective manufacturers, and based on standard- 
ized data models for different product types. An electroni- 
cally stored distributor catalog including links to 
manufacturer product information, modifications to the 
descriptions of selected items from the various 
manufacturers, and distributor specific data regarding 
availability, deliver schedules, and the like. Also included 
within the system is a subsystem for automatically updating 
the descriptions of items within the manufacturer catalogs, 
and a subsystem, responsive to the automatic updating 
subsystem, for maintaining the links to items within the 
distributor catalog. A terminal, operatively connected to the 
manufacturer catalogs and to the distributor catalog, may be 
provided for viewing item descriptions within the manufac- 
turer and distributor catalogs at the retail level of product 
distribution. A subsystem may be provided within the ter- 
minal for ordering items from the manufacturer and dis- 
tributor catalogs. 

According to an embodiment of the present invention, 
each manufacturer may access the Distributed Product Data 
Management Subsystem 34 to enter and maintain product 
information, including images, specifications, descriptions, 
and wholesale and/or retail pricing information. Each dis- 
tributor may access the Distributed Product Data Manage- 
ment Subsystem 34 to select and maintain the list of prod- 
ucts they will provide from any number of different 



manufacturers. Retailers, end users, and the like, can view 
the products offered by all network member distributors, 
including the manufacturer's product information, without 
concern that the information is outdated or inaccurate. The 

5 present invention facilitates the organization and presenta- 
tion of product information in numerous formats. For 
example, all products of a given type, all products by 
manufacturer, may be grouped and viewed together. Net- 
work members may also view product information directly 

1Q from a given manufacturer. 

Referring now to FIG. 6, the distribution of product 
information, according to one aspect of the present 
invention, is schematically illustrated. A variety of unique 
on-line product catalogs are shown being generated and 

15 updated without the need for distributors to reorganize and 
retransmit them as manufacturer specifications change. As 
shown, all products originate from manufacturers, (whether 
a single artisan fabricating unique works of art, or a major 
company creating thousands of reproductions of a single 

20 product). In all cases, a digital catalog record of textual 
descriptions, specifications, drawings, photographs, video 
clips, animation, price information, and any other desired 
information, is created for each product and made available 
to network members via the Network Service Distribution 

25 System 20. 

In the illustrated embodiment shown in FIG. 6, Manufac- 
turer 1 maintains an electronically stored catalog 200 of 
products for sale directly to distributors, retailers, and end 
users, each of whom is a network member. Each is allowed 

30 to view all or portions of Manufacturer l's catalog 200, 
according to Manufacturer l's discretion. End user 1 (208) 
may view the catalog 200 of Manufacturer 1 and may view 
the regional catalog 204 of Distributor 1 as indicated by 
single-arrowhead connectors 232. End User 1 (208) may 

35 purchase products from Retailer 1 (206) or from Manufac- 
turer 1, as indicated by double-arrowhead connectors 234. 
Distributor 1 maintains a catalog 202 of products purchased 
from Manufacturers 1, 2, and 3 via their respective catalogs 
200, 210, and 212, as indicated by double-arrowhead con- 

40 nectors 234. 

Distributor 1 markets and distributes selected products 
from the catalogs of Manufacturers 1, 2, and 3 (200, 210, 
212). The result is a unique catalog having a variety of 
products. Should any manufacturer update its product infor- 

45 mation via the Network Service Distribution System 20, it is 
automatically updated within Distributor l's general catalog 
202 and regional catalog 204. Because Distributor 1 allows 
Retailer 1 (206) and the End User 1 (208) to view its regional 
catalog 204, the updated product information from Manu- 

50 facturer 1 is available without Distributor 1 having to 
reformat or retransmit the product information. 

Still referring to FIG. 6, Manufacturer 2 supplies products 
to Distributor 1 and 2. Distributor 1 and 2 include informa- 
tion about these products within their respective catalogs 

55 202, 214. This results in unique catalogs of products avail- 
able to Retailer 1 (208) and Retailer 2 (218). In the illus- 
trated embodiment, Retailer 1 (208) may view Manufacturer 
2's catalog 210, as indicated by single-arrowhead connector 
232, even though purchasing of products is only available 

60 through Distributor 1. Retailer 2 (218) may view Manufac- 
turer 2's catalog 210, but can purchase only from Distributor 
2 via Distributor 2 's regional catalog 216. Manufacturer 3 is 
different from Manufacturer 2 in that only Distributors 1 and 
2 may view or purchase products from its catalog 212, as 

65 indicated by double-arrowhead connectors 234. In the illus- 
trated embodiment, a Specialized Provider has a unique 
catalog 220 of products purchased from Retailer 1 and 2 
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(206 t 218) as indicated by double-arrowhead connectors 
236. End User 1 (208) may view and purchase products from 
the Specialized Provider catalog 220 as indicated by double- 
arrowhead connector 238. 

As illustrated in FIG. 6, the present invention facilitates 
the creation and automatic maintenance of many electroni- 
cally stored product catalogs. In the illustrated embodiment, 
thirteen different catalog configurations containing products 
created by 3 different manufacturers are available to network 
members. Rather than thirteen different catalogs requiring 
reprinting or updating every time a manufacturer makes a 
change to specifications or product information, the present 
invention provides real-time updates as soon as they are 
made by a manufacturer. 

Both the Network Service Distribution System 20 and 
each Calendar-Driven Desktop System 60, according to the 
present invention, may be implemented via a variety of 
computing devices, including, but not limited to, mainframe 
computing systems, mini-computers, and personal comput- 
ers. It will be understood that a computer or other apparatus 
configured to execute the program code, embodied within 
computer usable media, operates as means for performing 
the various functions and carries out the methods of the 
various operations, according to the present invention. 
Stored computer, readable program code also acts as a 
means for carrying out the various methods and functions of 
the present invention. 

Computer readable program code means is provided for 
retrieving a copy of a first schedule from the network service 
distribution system, for changing at least one work stage 
starting or ending time in the copy of the first schedule, and 
for automatically changing the starting and ending times of 
work stages in the stored first schedule and a second stored 
schedule restrictively linked to the first schedule as a result 
of changes made to the copy of the first schedule. In 
particular, computer readable program code means is pro- 
vided for each of the following: comparing a copy of a first 
schedule with the first schedule stored within the network 
service distribution system to identify changed work stage 
starting and ending times; identifying whether a restrictive 
link exists between a work stage of a first schedule and a 
work stage of a second schedule; determining whether the 
identified restrictive link permits the starting or ending times 
of the second schedule to be changed; and automatically 
changing the starting and ending times of the second sched- 
ule work stage, thereby synchronizing the first and second 
stored schedules. 

The present invention may be written in various computer 
languages including, but not limited to, C++, Smalltalk, 
Java, and other conventional programming languages such 
as BASIC, FORTRAN and COBOL. The Network Service 
Distribution System 20 and the Calendar-Driven Desktop 
System 60 preferably run on current standard desktop com- 
puter operating systems such as, but not limited to, 
Windows®, Windows 95®, Windows NT®, UNIX®, and 
OS/2®. The present invention utilizes, in part, many stan- 
dard features of current desktop configurations, such as the 
ability to store data locally, connect to the Internet, and 
display visual information. 

The foregoing is illustrative of the present invention and 
is not to be construed as limiting thereof. Although a few 
exemplary embodiments of this invention have been 
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described, those skilled in the art will readily appreciate that 
many modifications are possible in the exemplary embodi- 
ments without materially departing from the novel teachings 
and advantages of this invention. Accordingly, all such 

5 modifications are intended to be included within the scope of 
this invention as defined in the claims. In the claims, 
means-plus-function clauses are intended to cover the struc- 
tures described herein as performing the recited function and 
not only structural equivalents but also equivalent structures. 

10 Therefore, it is to be understood that the foregoing is 
illustrative of the present invention and is not to be construed 
as limited to the specific embodiments disclosed, and that 
modifications to the disclosed embodiments, as well as other 
embodiments, are intended to be included within the scope 

15 of the appended claims. The invention is defined by the 
following claims, with equivalents of the claims to be 
included therein. 
What is claimed is: 

1. A computer based product catalog system for distrib- 
20 uting product information in real time to separate business 

entities within the building industry, comprising: 
a communications network; 

a first data processing system of a first product manufac- 
turer within the building industry in communication 
with the communications network, wherein the first 
data processing system comprises: 
a first product catalog that includes descriptions of first 
products which are manufactured by the first product 
manufacturer within the building industry; and 
first means for updating the descriptions of the first 

products in the first product catalog; 
a second data processing system of a second product 
manufacturer within the building industry in commu- 
nication with the communications network, wherein the 
second data processing system comprises: 
a second product catalog that includes descriptions of 
second products which are manufactured by the second 
product manufacturer within the building industry; and 
second means for updating the descriptions of the second 

products in the second product catalog; 
a third data processing system of a product distributor 
within the building industry in communication with the 
communications network, wherein the third data pro- 
cessing system comprises a third product catalog that 
includes selected ones of the descriptions of the first 
products and the second products; 
a retail terminal of a product retailer within the building 
industry in communication with the communications 
network, wherein the retail terminal comprises means 
for displaying product descriptions in the first, second, 
and third product catalogs; and 
third means, responsive to the first and second means, for 
55 automatically updating in real time the selected ones of 
the descriptions of the first and second products in the 
third product catalog. 

2. A computer based product catalog system according to 
claim 1 wherein the retail terminal further comprises order- 

60 ing means, for ordering items from the first, second, and 
third product catalogs, via the retail terminal. 
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[57] ABSTRACT 

Current corporate purchasing procedures are labor-intensive 
and therefore costly. The system enables an employee who 
needs an item which must be ordered from a supplier to 
select the item from an electronic catalog displayed on a 
personal computer and submit an order for approval and 
processing directly, by-passing both the normal paper 
approvals and the manual verification of the order by the 
organization's Purchasing department. It achieves this by 
means of an electronic catalog accessible from the employ- 
ee's own personal computer, and a computer network and 
associated services linking the enterprise to one or more 
suppliers. 
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1 2 

SYSTEM FOR ORDERING ITEMS OVER 3) a first end-user computer system comprising user 

COMPUTER NETWORK USING AN interface and able to access disk storage on a shadow 

ELECTRONIC CATALOG catalog server; 

4) a shadow catalog server which comprises a second 

FIELD OF THE INVENTION 5 computer system located within the enterprise whose 

This invention relates to a system for electronically link- disk stora S e can be accessed over a local area network 

ing a buyer and a seller in a purchasing cycle. bv one or . mor . e ©nd-users 1 computers in an efficient 

manner; said disk storage being being used to hold (1) 

INTRODUCTION TO THE INVENTION one or more electronic catalogs, and (2) program code 

10 comprising a a "Catalog Browser" capable of transmit- 

Current procurement procedures in corporations of all ting purchase orders to a master buyer and server; 

sizes are largely manual, or at best semi-automated by 5) a masler buyer server comprising a third computer 

electronic mail, and are as a consequence labor-intensive tem located wUhin an enteiprise containing (1) 

and costly. Typical procedures operate as described below. program ^ comprising an order manager and a 

Refer to the attached drawings, which make the description is purch ase order workflow which takes purchase orders 

easier to follow: f rom one ore more enc j_ user computers and and con- 

1. Typically, an employee requiring some item (such as a trols their flow through the enterprise's business pro- 
piece of office equipment) will look for it in a supplier's cesses before transmitting them over a network to the 
catalog. Such catalogs may be at the user's workstation, but supplier; and (2) a purchase order data base. 

are often kept in some central location for general reference 20 The advantages of the novel system are appreciated by 

(see FIG. 1, numeral 10). contrasting it to the prior art summarized above. In 

2. The employee transcribes information (such as part particular, the concept of corporations ordering items from 
numbers and price) from the catalog on to a purchase order suppliers over a computer network is well-established, and 
(FIG. 1, step 01). 2g has led to the formalization of EDI (electronic data 

3. The completed purchase order then normally goes interchange). 

through an approval process, which may, depending on the ^ concept of consumers or end-users (the people who 

value of the order and the nature of the items on it, require wlU ultimately make use of an item) ordering items from 

several sign-offs by people within the corporation with electronic catalogs over a (usually public) network is also 

budgetary responsibilities (FIG. 1 step 02). 30 well-established. Public network services such as Prodigy 

, ~, . , . . t 4 . . . (tm), America On Line (tm) and Compuserve (tm) allow 

4. The purchase order is then sent to the purchasing u *u . *u • • . ■ . j i_ 

j ; c ,u- *■ u- u u i .u ■ c subscribers to their services to select consumer and house- 
department of the corporation, which checks the mforma- . . , - . . . . , .. 

in. ■ | • i*j e • iU **u u • nold ltems f fom catalogs placed there by suppliers. The 

don. These checks include venfymg hat the .terns are being ^ * d £ mlbeaa J. t h Ze, and the 

ordered from the correct suppher: the same Uem may be cos , cha y d H insl a ^ edit card . Such syslems nav ; to date 

offered by more than one supplier, but contracts are fre- 35 in aIu u u . , 4 . 

4l 7 - ■ 1 .* . . ^-1 -4 4 u only allowed the subscriber to access one supplier s catalog 

quently negotiated that require a particular item to be ^ £ ( - me 6 

procured from only one of these suppliers, and the Purchas- *. . . , . . e . . . . 

in de artment has to verif this (FIG 1 ste 03) may 00 neither of the above approaches is a 

ing epa men as o ven y is ^ , s ep j, complete solution to the problem addressed by the disclosed 

5. The Purchasing department then sends the Purchase invention, which is to allow end-users within a corporation 
Order to the supplier (FIG. 1, step 04). 40 (0 ordef necessary items ^ if mey were consumers ordering 

The process described above can take weeks if not items for their own use and at their own expense, but to have 

months. such orders then flow through the enterprise's normal busi- 

At the other end of the procurement process, printing and ness controls before being submitted to the supplier. The 

distributing the traditional paper catalog is also a labor- disclosed invention also goes beyond these solutions in 

intensive and costly process (see FIG. 2, numeral 12), 45 allowing the catalog an end -user sees to be sub-setted and 

especially since catalogs are usually of high quality in terms otherwise modified from the supplier's general catalog; in 

of art-work and color reproduction (FIG. 2, step 01) but may facilitating comparisons between items from several suppli- 

be distributed at no charge to potential buyers. The long ers; and in permitting orders to be generated containing 

production time for a typical catalog (of the order of several 5Q items from several suppliers. 

months) causes additional problems when it includes items rt „ w „„ , 

such as personal computers and consumer electronics where BRIEF DESCRIPTION OF THE DRAWING 

prices are highly volatile. Vendors have sought a number of The invention is illustrated in the accompanying drawings 

solutions to this problem, the most common being to omit which: 

prices from ihe catalog altogether and issue a separate list of $$ mGS t and 2 show prior art purchasing and catalog 

prices (FIG. 2, step 2) several times throughout the lifetime creation processes; 

of the catalog. FIG. 3 shows an end-user environment; 

In response to this situation, we now disclose a novel FIG. 4 shows a client environment; 

system for ordering items. The system comprises: _ , . - - t ~ , 

' . .. . .. , FIG. 5 shows a sample screen for features of the present 

1) means tor receiving and processing images and text go invention* 

from a plurality of catalog content providers for creal- ' . ...... 

. ■ . • • 1 , ( i FIG. 6 shows an invention topological overview; 

ing and maintaining one or more electronic catalogs in r 0 . 

a central location for subsequent distribution over a HG 7 provides an overview of data flow between logical 

computer network; servers; 

2) means for receiving supplier's price and catalog 65 FIG 8 shows catalo & enablement; 
changes and propagating them to one or more selected FIG. 9 shows content librarian workflow; 
buyers over a computer network; FIG. 10 shows image librarian workflow; 
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FIG. 11 shows a protocol support for filemover; and in addition to a communications gateway computer 82. 

FIG. 12 shows a distributed procurement service. Token ring 76 services catalog file and reference services 

hptait cn npcpDiDTirwr r\v tuc computer system 72, catalog and software distribution 

DETAILED ^^FTON OF THE ^ 74> and PS/2 . 0 S/2 78. Token ring 94 services system 

INVhN HON 5 and filc mon i lor scrvcr 96 and PS/2-OS/2 92. The local area 

The disclosed invention automates much of the manual network backbone 98 further supports and EDI gateway 

processing described above. The disclosed invention pref- pricing decision computer 80. Catalog maintenance activi- 

erably is used in the following way (FIGS. 3 t 4 numerals 14, lies are input to the Maintenance Entity 100 from remote 

16 illustrate preferred steps involved): terminals 52 and 54 via token ring 56 through T-l leased 

1. An employee 17 preferably accesses one or more 10 lines <52. Application development occurs remotely, item 58, 
electronic catalogs 24 stored on a shadow catalog server 22, and k communicated to the operations environment through 
accessed via a local area network 20 preferably by means of application development Token R.inr; TORONTO 60 and 
a employee workstation 18. These catalogs contain only routed t0 development server 84. 

those items for which a price has been negotiated between The client environment is shown in the lower segment of 

the enterprise and a particular supplier, so the verification by 15 FIG. 6, defined by shadow server 106 which maintains a 

the enterprise's Purchasing department described above is customized copy of the master catalog for distribution to 

obviated. local clients 102 and 104. Purchase orders are received by a 

2. The employee selects items from the catalogs prefer- L° c ^ buvcr master server 86 from a data pathway connect- 
ably with a mouse or similar device. Catalog items may be in S remote shadow LAN 108 with local buyer master LAN 
displayed with pictures, descriptions and other information 20 88 * ^ Bu y er Master Server also performs the server 
in a fashion similar to a paper catalog. Where similar items function in the following capacities; order processing from 
are available, a "Compare" icon can be selected on the bu y er clients 90 > approval and call back. The Buyer Master 
screen, causing the items to be listed side by side, with Server communicates with the operations environment of 
differences highlighted. Items can be located by searching lbc enterprise through a 56 Kb switched or leased TCP/IP 
down the taxonomy tree of the catalog (much as one 25 ^ ne ^* 

searches through a paper catalog by finding the appropriate The Buyer Master Server also interacts with the Range of 

general section and then looking for a particular item), or by Legacy Systems which consists of a host computer 64 

entering a search word or phrase. connected to a COMM FEP 66, a MINI computer 68, and a 

3. Items selected may be accumulated in a "clip-board", p p 7°' V 10 provided by the Maintenance Entity 
a temporary holding area on the user's computer disk. When 30 distinguish this invention from the electronic catalogs 
all required items have been selected, the employee selects offered by public networks such as Prodigy (tm) and 
a "Submit" icon. This causes the selected items in the Compuserve(tm), which do no more than route messages 
clip-board to be sent' to the appropriate approvers as a fr° m me subscriber to the supplier. The Maintenance Entity 
Purchase Order 30. It should be noted that there is no manual services act as a single point of contact to all the suppliers 
transcription of ordering information from the catalog to the 3S on one side and all the buyers on the other. Existing 
purchase order (since that is performed by the disclosed networks merely link them in a many-to-many relationship, 
system). Tn e advantages of this approach are clear: for example, a 

4. After the order has passed through the enterprise's supplier has only to provide a change to a catalog item once 
normal (legacy) business systems, including a workflow 4Q to the Maintenance Entity, which then disseminates it to the 
definition database 26, a purchase order database 28, and affected users. 

other existing corporate applications 32, it is forwarded to This aspect of the invention is summarized in FIG. 7, 

the Maintenance Entity via the Network 34. From there it is numeral 22 which shows the data flows already mentioned 

sent to the supplier for fulfilment in a traditional way. in FIGS. 3, 4 as well as some others which were omitted 

5. The employee can at any time review the purchase 45 from tbc ori &™ ] description for the sake of clarity. The 
orders already submitted; cancel them if they have not yet omitted data flows include details specific to both the 
been shipped; and print reports. Operations environment and the Client environment: 

The other end of this process involves capturing catalog L Detailsof the Operations Environment 125 Networking 

content (text and images as well as price information) in software and services software including; a PRICING DAE- 

electronic form. As long as catalog content providers and 50 M0N 132 wnich receives purchase orders, change orders 

suppliers continue to publish traditional paper catalogs side and cancellation order acknowledgments from the ORDER 

by side with the electronic versions, this activity does not PROCESSING SVR 154 located in the Client Environment 

displace the current manual process. 123 via an EDI GATE Way 130. The Pricing Daemon 132 

The two ends of this automated solution, the supplier side in turn provides pricing updates and base catalog entries to 

and the buyer side, may be brought together by means of a 55 catalo S filc servcrs ' CAT FILE SERVERS 140. 

computer network and associated service offerings. FIG. 6, The operations environment further includes distribution 

shows an overall network topology 20 or the initial management tools, defined generally by CMVC 134. The 

implementation, with the three major pieces (supplier, buyer CMVC consists of a Subscription List 138 which resides on 

and Network Central) clearly distinguished. Suppliers 50 a server in the form of topology tables 136. The subscription 

provide e-mail directly to the maintenance entity 100 and to 6 o lisl sources multiple reference servers 142, all of which are 

the communications gateway 82 via an EDI mail box 110. contained within a distribution server 144. The reference 

Suppliers also provide CD's and diskettes for the to lermi- servers source a combination server comprised of a system 

nals 52 and 54 for the purpose of catalog creation and monitor server 146 and a file mover server 148. 

maintenance. Terminals 53 and 54 communicate with the 1. Details of the Client Environment 123 

maintenance entity through Token Ring THORNWOOD 56 . 65 Comprised of a Shadow Server 150 consisting of Browser 

Maintenance Entity 100 consists of a local area network Dynamic link libraries DLLs 152. The Browser DLLs 

backbone 98 which supports multiple token rings 76 and 94 receive catalog data from the Order Processing Server 154 
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and in lurn output the Browser DLLs and customized 
catalogs, during a client browse session to a buyer (client) 
156. 

The Order Processing Server receives inputs from four 
separate sources; (1) Buyers (clients) 156 (2) the Approval 5 
Server 158 (3) the CallBack Server 160 which services the 
transfer of files to and from legacy systems 164 and (4) the 
File Mover Server 148, which is part of the Operations 
Environment. 

This aspect of the invention preferably comprises (see 10 
FIG. 7) three major components: 

1. Catalog creation and maintenance tools (shown at the 
top of Fig. 7). Catalog creation is defined by item 122, the 
SELLER AND PROVIDER ENVIRONMENT consisting of 
EDI MAIL BOX 122, CONTENT PROVIDER 124, and 
CD's & Diskettes 126. 

Catalog maintenance is defined by item 127, CATALOG 
MAINTENANCE ENVIRONMENT, which includes item 
128, CATALOG MAINTENANCE CLIENTS which 20 
receives inputs from CDS & Diskettes 126 and additions and 
changes concerning catalog entries & update, pricing 
updates, and subscriptions from CAT FILE SERVERS 140. 

2. Catalog browsing and purchasing software (the client 
environment shown in the lower segment of FIG. 7); and, 25 

3. Networking software and services (the Operations 
environment shown in the middle segment of FIG. 7) 
defined by OPERATIONS ENVIRONMENT 125. 

Catalog Creation Maintenance 30 

The preferred embodiment is made up of two main 
elements: 

Content mianagement tools to receive, process, and man- 
age images 208 and text 212 from content providers 35 
200 for the creation of an EPS (Electronic Purchasing 
Service) master catalog. An overview of this process is 
shown in FIG. 8, numeral and Text 212 from content 
provides 200 are first converted through conversion 
units 210, 214 also, including conversion units, 218 and 40 
222 from third party converters 202, the graphics and 
text are then and combined with content from indepen- 
dent image providers 220 to create catalogs 216 and 
224 constituting third party catalogs 204 which are then 
combined at an EPS catalog stage 206 to form EPS 45 
(Electronic Purchasing Service) catalog 226 and dis- 
tributed to buyers 230 via EPS subscription 228; 

These enable EPS Operations staff to create and manage 
catalog information in the merchandise database such as the 
price, description, and visual representation of each item. 50 

Distribution management tools to receive vendors' price 
and catalog updates, as well as to propagate the changes 
to the customers* Buyer Master servers. 
Content Management Tools 

The EPS Content Management tools preferably comprise: 55 

FotoFarm; 

Product Editor; 

Folder Editor; 

Subscription List Editor; 60 
N AM2D AT/NAM2G RP. 
FotoFarm 

This collection of utilities may be used to convert text and 
images from the content providers 200, 250 and 280. The 
workflows of these Iwo activities are shown schematically in 65 
FIGS. 9, 10 numerals 26, 28. Supported functions may 
include: 
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Receive, store, and archive source images 282 and text 

files 252 and 282. 
First-level validity check of source media 254, 284 and 

286. 

Assign EPS unique filename and update the index files 
258, 284. 

Create master catalog's subchapters and folders, and 
populate them with the relevant contents 260 292. 

Trigger down-stream re-creation or subscription catalogs 
(see below) when EPS catalog updates occur 260 292. 

Process images received from content providers in batch 
model 256: 

Delta cropping of image by specifying new crop coordi- 
nates 288. 

Generate multiple resolution versions of images. 
Convert 24-bit to 8-bit dither with palette matching. 
Enable re-scheduling of batch process for related infor- 
mation. 

Allow multiple images to be proofed at the same time. 

Manage registries of 260 292: 

Shared disk storage for various purposes; 

Providers of images, text, or EDI content and services; 

All top-level books in the EPS Catalog Server. 

Product Editor 

This ITS (Iterative Transaction Systems) application 
enables EPS Operations staff to: 

View multiple product descriptions at a time; 
Associate images with product handle; 
Save, import, and create templates; 
View and edit product descriptions. 
Folder Editor 

A sample screen from this tool is shown as FIG, 11, 
numeral 30. This tool enables Operations Staff to: 
View master catalog space. 

Organize and arrange products into groupings, i.e., 
manipulate Catalog topology. 

Search: Keyword, Power Search (Attribute, Taxonomy). 
Subscription List Editor 

This uses code from the Folder Editor and Search Engine, 
with additional functions, to enable Operations staff to: 

Save subscription profiles; 

Update/edit Distribution Frequency via manual operation; 

Update/edit Distribution Frequency automatically; 

Generate flat or hierarchical browser space; 

Send newly created subscription list to Catalog Server, 
NAM2DTA/NAM2GRP 

NAM2DTA is a stand-alone GML parser that converts 
tagged source files to catalog objects. NAM2GRP is a 
stand-alone GML parser that converts tagged source files to 
catalog folders. 

Distribution Management Tools 

Distribution Management concerns itself with getting 
data from Network Central out to the customers* computers 
on the network in such a way that each computer receives 
only that data (catalog items and price information) which it 
needs. The EPS Distribution Management tools preferably 
comprise: 

Distribution Manager with GUI query tool; 
Catalog daemon (CATD); 
File Mover. 
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Distribution Manager ments and maximizes the responsiveness of the total system 
Responsible for preferably by employing a primary model consisting of two 
Price Update (Catalog Monitor); major components, a buyer side component 330 which 
Catalog Update (Catalog Monitor); communicates over a network bridge with a premises corn- 
Automated EDI Processing and Distribution (Update 5 ponent 332 (see FIG. 12, numeral 32): 

Daemon); 1. An end-user computer system 333 attached to a Local 
Acknowledgement Processing; Area Network or LAN, containing the usci interface; 
Update DB2/2 Tables. 2. A "shadow catalog server", 331 (FIG. 12-2) with disk 
Catalog Daemon (CATD) storage that can be accessed over a LAN by one or more 
This software runs in customers' servers and polls mail- to end -users' computers, the disk storage being used to hold 
boxes to apply updates, and preferably monitors channels one or more electronic catalogs 328 and program code 331 
for action objects including: Images; Applications; Prices; to enable browsing of the catalog and transmitting purchase 
Catalog descriptions. It preferably can Execute action speci- orders to the "buyer master server" 324; 
fled in action object; Forward acknowledgement objects to 3. A "master buyer server" 324 (FIG. 12-3), which is a 
parent; and is Used together with File Mover daemon to is computer system within the enterprise containing (1) pro- 
verify file movement. gram code (described below) which can lake purchase 
Filemover 300 orders 332 from one or more end-user computers and control 
This is the communication layer of EPS which moves files their flow through the enterprise's business processes, as 
between systems. In particular, it drives the movement of described under "Workflow" below, before transmitting 
data throughout the network for price up-dates and purchase 20 them over a network to the supplier via the Maintenance 
orders. Entity 320 and (2) a to a Purchase Order data base 322 that 

Filemover uses a simple mail-like mechanism in which can be accessed over a LAN 326. 

files are moved from OUTBOX directories to INBOX A preferred embodiment of the above comprises: 

directories, which can span network attached systems. It has Order Manager and Catalog Browser 

no knowledge of the type or structure of the file it moves, 25 This function runs on the end-user's personal computer, 

and treats them all as binary blob data. Hence no code page although the code would normally reside on disk storage in 

translation or character set translation is attempted. a catalog shadow server machine. It provides the following 

Filemover is a Point-to-Point protocol and does not pro- main function to an employee using the system: 

vide any internal routing mechanism. Routing can be pro- Log on/Password Security 

vided outside of the Filemover, however, by: 30 Login 

Utilizing the routing mechanisms of the underlying Log into EPS 

protocols, e.g., TCP/IP. Will only work across Track User ID for all transactions arising from this 

machines running in a single internetwork with the session. 

same protocol , rtirmv . , „ Additional Order Manager functions may be enabled or 

Using Catalog Daemon (CATD) to provide routing by disabled based on the ] • fi!e 

forwarding files across intermediate nodes. It works , , . , 

across internetworks with different communication U f r s < lccts from ll5t of a^ 0 " 2 ^ uscrs - 

protocols but its network path must be hard-coded ^ atal0 S ° ro ' wser I _ . „ . 

within the catalog files being sent. Browse Product Ima S cs > Text and ?nccs 

Filemover enables the EPS to: 40 Able 10 P a S e forward or backward. 

Move files of any size and takes care of splitting and Quick return to top menu page from any part of the 

reassemblying the files when the underlying communication catalog. 

software has a limitation on the file size. Q u i c k return to the table of contents from any part of the 

Verify and confirm both file movement and ability to catalog. 

move files (e.g., checks disk storage). Display previous page at top of screen, with links to 

Support file movement over systems connected with navigation log 

multiple protocols (shown schematically in Fig. 11): , are dis |a d . BMp format 

IPX/SPX 306 

Two separate image files are kept for OS/2 and Windows. 

NetBIOS 304 5Q Sce abo « FotoFarm » supra 

TCP/IP 310 

« _ «. t Text The Browser may select zero, one, or more ordered 

Support rile movement over: - . . , J , 

. . r Avr r^- <» * *v ■ sets of descriptive phrases. 
Dial-up connection (SLIP and LAN Distance 312) via 

modems Pnces ' 

«*v i • . j t avt iwaxt Select Product Based on Single Keyword 

Dedicated LAN or WAN connection 55 

Support Store and Forwarding of files 302. on index search. 

SNA APPC 308 Index search is launched with user's action on an icon 

Client Environment represented by a magnifying glass. 

Recall that the Client Environment (FIG, 7) comprises Search by product type or manufacturer's name, 

two principal components: 60 t0 c |i pboard f or f urtner processing. 

1. An electronic catalog in a format that can be browsed, Compare Products (max. 4) 
searched and ordered from, by a corporate employee with no _ „ , „ 

training in Purchasing procedures; Com P are U P 10 four ltems from the same cate 8 0r y- 

2. Software that controls the flow of a purchase order End user selects this option by clicking on a "Compare" 
through an enterprise's procurement procedures. 65 ic °n represented by a scale. 

The preferred embodiment of the above software and Varying features amongst the compared products are 

related manual processing minimizes data storage require- highlighted in bold text. 
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Product Clip Board The quantity of line items can be decreased to zero. 

Select items on Product Listing for adding to clipboard. A line item can be deleted once an order has been placed 

Add item on Product Page to clipboard. with a vendor and is being fulfilled by the vendor. 

Delete an item in the clipboard. Allow client to modify other fields such as requested ship 

Change the quantity of an item in the clipboard. 5 date, shipping and billing address, add comments to line 

dear the clipboard to remove ALL items. ilems ( c -g • a banking institution). 

Save the clipboard (to a file). Possibly allow client to switch partnumbets, delete line 

Submit the clipboard (as a purchase request). ^ ms . ad r d ncw H ° c ilcms - 

Show the items on the clipboard. Change l^ggmg^eportmg 

, r . , , .. . , N 10 Changes to the POs are recorded in the logs and can be 

View clipboards (i.e. saved clipboard files). J. t . _ t °^ 

ivu r> *• • ■ , r lL accessed by the report generation functions. 

Purchase Request Generation Select the recipient of the D ~ . , . ' r 6 

. j •„ r , t, • ■ » i- , • i * - PO Maintenance 

purchased items from a list. The recipient list is kept in a B row se POs 

local disk, and its entries can be added, changed, or n nrb . . , . , . - 

, & Group existing POs in ciapteus with summary lnforma- 

remove . 15 ( . Qn mc i U( j mg: 

Classify all line items into capital and expense items. n , , 

' r . . . r Request number. 

Ask for budget number for capital items. Requester 

Ask for engagement number for expense items. Recipient 

Display generated purchase request for confirmation. ^ 

Select approver from list to submit request to. 20 j ota j 

Add comments to purchase request. oTsusiness. 

Send purchase request to approver. ScroU thrQUgh a „ Mne items 

Save purchase request as clipboard. Sorl line items by column headings in the following order: 

Cancel submission of purchase request. Sort numcr ic columns from high to low or low lo high. 

Print Clipboard: This function is in addition to and Sorl alpha5etic ^ mx& from A to Z or Z to A. 

separate from, the report generation functions which use yiew details of ^ items b clicking on them 

DB2/2 report generators It enables users without access to Seafch ^ specific groups of po s and purchase requests 

DB2/2 to print a chpboard or submitted order from their own by Requester Name) Reques ter Date, and Request Number, 

workstations. 30 The search results can be grouped into a chapter. 

The supported functions include: View Approvers 

Generate printed output from client application for the Enables user to look up list table of associated approvers 

contents of the clipboard. f or a po. 

Can also be used for printing a submitted order. Approvers are item-based; i.e., each item has its own 

Able to generate output for various printer formats includ- 3S approver. 

ing Postscript. May have to go through some type of Enables user to view approval data for each item, with the 

metafile generation process. approvers name, decision, and date of action. 

Needs to work in both OS/2 and Windows. Check Status 

Purchase Order Creation Enables users lo check current status of POs. * When 

Multiple Sellers on One PO 40 orders arc placed, vendors send acknowledgements and 

Each line item in a purchase request could be sent to a status messages via EDI. These are reflected in the updates 

different vendor. This requires that information such as the to the status of line items, with the dale of the status change, 

shipping and billing address be stored on a line item level, The approval status of each order or request can also be 

rather than at the header level for a purchase order. These checked, 

multiple sellers include those whose products are not listed 45 Cancel POs 

on the catalogs. Enables users or administrators to cancel POs or purchase 

Electronic PO requests. This is dependent on whether the order has passed 

This is to forward the purchase orders electronically to the the deadline for the change to be effective. Vendors restrict 

vendors via the EPS. system. Data includes type of the set of order slates against which a PO can be canceled, 

transaction, required data as defined by EDI standards for a 50 For example, if the item has been shipped, the order cannot 

850 PO such as PO number, date, name & address, customer be canceled. EDI Vendors must be able to support Cancel/ 

ID, customer master record for shipping and billing infer- Change 860 transactions and their subsequent acknowledge- 

mation. ments. 

Print Paper PO The end user will be prompted for confirmation of can- 
Print PO by vendor in a multi-vendor PO 55 cellation request prior to processing. 
Sub-function of the common printing functions described Upon confirmation of cancellation, the order is moved to 
in "Report Generation", infra. *e Canceled Requests chapter. 

PO Processing Note 

Manual Status Update ^ lne po nas a l readv been sent lo the vendor, an addi- 

Purchaser can update status of PO manually after receiv- 60 jional EDI (860) transaction is generated and budgets cred- 

ing acknowledgements, status updates, etc. from vendors via x ^&- 

fax, phone, or mail. Changes to the PO can then be saved to Approvers 

the DB2/2 database on the Purchasing Server. ™ s function is required for customers who arc not using 

Line Item Modifications by Client c * mail approval. 

The quantity of line items can be increased or decreased 65 Requires end-user interface to be modified to make the 

prior to order submission. After an order has been submitted, approver line ilems editable, 

the quantity can only be decreased. Changes must be saved back to the database. 
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Delete Approvers 

This function is required for customers who are not using 
e-mail approval. 
Order Manager Admistration 
Budgets 

All line items for capital purchases are charged against the 
capital expense budgets. 

Budget Information: Each budget has the following infor- 
mation: 

Budget number 

LOB (line of business) 

Line of business related to the purchase. 

Allocated 

Amount allocated to the budget. 
Current Requisition 

Amount associated with all active orders. 
Ordered 

Amount for orders that have been sent to vendors. 
Balance 

Balance amount available in the budget. 
Active 

Yes for an active budget. 

No indicates a budget that has been closed and no 

expenditure can be charged against it. 
Create new capital budget: The following information is 
preferably required: 
Budget number 
Amount allocated 
Amount allocated to the budget. 
Active status 

A Yes to indicate that it is active. 
LOB (line of business) 
Line of business the budget is assigned to. 
Description of budget 

Brief description of the purpose of the budget. 
Change existing budget: Changes can be made to the 
following aspects of the capital expense budget: 
Amount allocated 
Amount allocated to the budget. 
Active status 

A Yes to indicate that it is active. 
Description of Budget 

Brief description of the Purpose of the Budget. 

All changes are logged to the change history log, which 
can be viewed. 

Delete existing budget: This function may be used to clear 
existing budgets at the end of a fiscal year. 

There will be a prompt for the user to confirm deletion of 
the budget amount. 
View budget history 

Alt changes to the allocated amount and status of the 
budget, as well as all expenditures are logged. 

Each transaction is logged with a brief description of the 
activity attached. 

The last 100 transactions are logged. 

This view function is applicable to both active and 
inactive budgets. 

Import budget guidelines: This is to enable the import of 
budgets from SAP, or another accounting interface, for the 
initial budget creation. 

Track budget: All line items in a PO get charged to either 
an expense or capital budget. Any modifications to the PO 
requires that the budget balances get updated. 
User Profiles 

The following functions are provided: 
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Add new users Authorize new users to the list of autho- 
rized users. 
Delete User 

Update current user profile 
5 Ship/Bill Update (Per Site) 

This is to enable the purchasing administrator to maintain 
the shipping and billing addresses of all locations within a 
Customer enterprise. These addresses are referenced by POs 
to define the shipping and billing destinations. The sup- 
10 ported functions include: 
Add new address; 
Update current address; 
Delete current address; 
is Vendor Info Update 

This is to enable the purchasing administrator to maintain 
the EDI vendor addresses for confirmation of shipment and 
billing, as well as status updates. The supported functions 
include: 
20 Add new address; 

Update current address; 
Delete vendor address. 
Define Company Policy For Captial/Expenses Purchases 
Line of Business 
Add new line of business; 
Update line of business information; 
Delete line of business. 
Report Generation 
30 This includes the common printing functions for both the 
reports and purchase orders. They include: 
Commodity reports; 
Line cost reports; 
35 Order modification reports; 
Budget modification reports; 
Customized reports. 
Approval Workflow 
Approval workflow is controlled by the Approval Man- 
40 ager residing in the Purchase Server in the customer's site. 
This workflow of the purchase orders between the customer 
and vendors is enforced by a PO approval process defined by 
the customer. Its functions include: 

Keep track of a PO*s approval status from the moment a 
purchase requisition is generated. Appropriate actions 
are taken to forward the purchase requisition to the 
predefined approvers to be approved or rejected. 
Interface with the customers* electronic mail systems to 
50 post approval notifications for the necessary action by 
designated PO approvers. 
Provide separate ITS client application to allow PO 
approvers to approve purchase requisitions directly 
from within the EPS system rather than from the 
55 external email system. 
Approval Policy Configuration 

Set up Lotus Notes DB to specify approver hierarchy. 

Use of REXX code to customise approval hierarchy. 
Approval Data 

60 Store approval data for POs in DB2/2 PODB; 

Store list of approvers in Lotus Notes; 

Entry point API (call-out) to support accessing approvers 
from external systems. 
6S Approval List Generation 

Print approver Lists from Lotus Notes; 

View approver Lists from Lotus Notes; 



45 
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Lotus Notes interface to create and update approvers list expected to notify the EPS Server when the specific 

(company wide); task is completed. 

REXX code to specify approval policy given PO and list API Architecture 

of approvers; A brief description of the API architecture is necessary for 

Generate Approvers service application 158 to commu- 5 an understanding of the API functions and action calls. 

nicate with client server API CORDER PROCESSING Essentially, the API is made up of five layers, as shown in 

SVR 154 (per PO). nG * 5: 

Approval List Processing X lavcr 38 B the ITS application layer which 

Approvers can receive email messages via an E-MAIL inlc 1 rfaces ^ ITS clien u l to ITS client 

SERVER 162 notifying them that they need to approve 10 a Pf a £ on t0 thc C lavcr fo ' °™"d transmission 

various purchase requisitions. ° v < ; uy ^ r A JJ? 

.. _ • •« L i r t . * T . . . -i Y la y cr 40 This is the non-ITS application layer which 
Mail routing support is available for Lotus Notes, cc:?!ral, • . c ... i™, rr 4 ... ' trT — 
H M ft M I interfaces with non-ITS applications to deliver non-ITS 
and Microsoft Mail. dicn( app i ication rcqU csts to the C layer for onward trans- 
Snapshot Database Within Lotus Notes , r • • *T # . w „,„ 
J?. * . ■ . o .... 15 mission to the Buyer Master, 
u ^Sc S c a fi,nCt '°^ 'u s y nchro °l se 1,16 «»fo™ation between c , 42 ^ fc ^ common , tha , intcrface the x 
the EPS Server and the I^tus Notes server. and y u ^ (he M { „ lakes , ication level daU 

I P Zr C i'?^ ■ m f° teS t , w structures from X or Y layers, converts them into low level 

A help database is available from w.th.n Lotus Notes as communicalion data and invokes M layer 

a Notes database. 2Q w j tn these data buffers to communicate with the EPS Server. 

Ap^wMaMBW C1 ' cnt . M layer 44 This message layer is the lowest level EPS API 

This ITS chent application is for approvers who do not commur)ication la „ uses the 1TS coMM 48 API to 

want to receive approval notification from an email system handl(j Q , ifi(; ^^cation functions . „ hand i e 

external to EPS. It enables approvers to log on to the EPS commumcations data buffers instead of a ppi icalion leV el 

Purchasing Server and approve or reject purchase requisi- 2J datfl structures _ 

Df^w in ^ layer This is a server interface layer and handles 

™ , « , c L t , . , . , functions between the C layer of EPS Server and the OM 

The flow of the purchase order through an enterprise s s erver i aver 47 

approval and other financial processes varies with each , n addui ^ Eps clienWServer Apj has , M of 

enterprise. The disclosed system contains workflow logic 0MServef m& t0 rt client requested actions on the 

implemented as a Finite State Machine. This is a table £ps Servef [mm (he § , ^ 

specifying how the system is to change state in response to ^pj s 

specified inputs, and what actions it should take when each Logfofly, the EPS Client/Server APIs can be grouped into 

transition takes place. Such a table can be easily tailored to £ Qur g reas . 

fit the needs of a particular enterprise. Application Program 35 information 

Interfaces (APIs) in the generic state transitions supplied . i j .•_ a *• j .* . ^ . jo 

„ 6 • . • 1 1 These include the functions and actions to Get and Save 

with the system allow an enterprise to invoke and pass . . c , c . , . . . .u me c 

. r ' Jr • t i r a data of predefined datatypes to the EPS Server, 

mformation to and from existing computer applications and " J * 

data bases (which could include the enterprise's "legacy" Monitors 

purchasing system) as shown in FIG. 4 step 02. Services 

In the preferred embodiment, The EPS Client/Server Security 

application programming interface (API) provides client These validate clients and restrict the level of access, 

applications with a set of functions and action calls to These include: Logon, Logoff, Connect, and Disconnect, 

communicate with the EPS Server for managing purchase TYtfi NETWORK ENVIRONMENT 

orders within the customer's environment. It can also be Ae 1M t . , .... c . , w^^o , 

, , . i- „• . i „„m. A n * n 45 Network Central (shown in the middle of both FIGS. 6, 

used by any customer applications to work with the data m . , v , . I 

available from the server 7 > of one or morc compute 15 and program code of 

™ AT1T , ' . r i- » i * ™ the type located in IBM's Ad vantis network, which provide 

The API supports three types of client applications: . J *\ . . e * 

L - J ,. - four principal functions: 

Interactive Transaction System (ITS) applications , r . . c . , c t . . 

™ . u.u w, ii a 1. receipt of purchase orders from the master buyer 

These are clients written with the ITS toolkit and using the * v J 

,™ ... . . -I ■ . p 50 servers of one or more enterprises; 

ITS runtime to provide the user interface. _ . m , . r ' . 

xr ™„ 2. passing EDI transactions to and from suppliers; 

Non-ITS applications . ... ^ . . 

These are clients that have user interfaces other than ITS. 3 < storin S catalo 8 ^formation for transmission to buyers; 

EPS system extensions 4 ' the distribution of price information. 

These are ITS and non-ITS applications registered with 5S In addition, personnel at Network Central may perform 

the Purchase Order workflow of the EPS server, and can be many or all of the activities described under "Catalog 

classified into two categories: Creation/Maintenance" above. 

1. EPS Monitors Overview of EDI 

Registered against a certain state in the Purchase Order u ^ Electronic Data Interchange (EDI) is a standard for 
workflow and are notified whenever any purchase 60 the exchange of business data. It defines: 
request enters that state. The notification will be Communicalion wrappers, which are usually handled by 
received asynchronously with the purchase request a communication package from a Value Added Net- 
continuing within the workflow. wo * ( VAN ) providing EDI mailboxes). 

2. EPS Services The ASCII character set. 
Registered with the EPS Server and introduce a new state 65 Various transactions, each with an ID 

in the Purchase Order workflow. They are notified The order and hierarchy of data within each of the 

whenever any purchase request enters that state, and are transactions. 
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The type and lenglh restrictions for each piece of data. 

There are two major EDI standards— ASC X12 which is 
the standard for the United States, and UN/EDI FACT, which 
is the general standard adopted by countries outside of the 
U.S. 

EPS EDI Implementation 

Customers may be connected to a system like the IBM 
&EPS. via non-EDI links, sending their purchase orders 
over 56khs lines. The EDI Gateway translates and maps 
these communication into EDT messages before using the 
FileMover mechanism to send them to vendors via its EDI 
mailbox on the Ad van t is network. Vendors* acknowledge- 
ments and status updates are transmitted as EDI messages to 
the Advantis mailbox. The EDI Gateway translates them to 
the EPS format and updates the PO status accordingly. 

Currently, the EDI Gateway consists of the EDILISTS 
application as well as the IEBASE program provided by 
Advantis to connect to the Advantis network using LU6.2 
communication protocol. The gateway logs and tracks all 
EDI transactions for diagnostic purposes; it can also alert the 
Network operator for the necessary recovery action when it 
encounters any unexpected event. 

The preferred embodiment supports the following EDI 
transactions: 

832-Create Catalog Content. 

850-Purchase Order. 

855- Order Acceptance. 

856- Shipping Order Status. 
860-Change/Cancel Order. 
865 and 870-Order Status. 
997-Acknowledge Receipt of Order. 

Other Gateway Functions 

Gateway EDI in-box and PO in -box monitoring 

Look for new PO request and translate to EDI. 

Look for new EDI transaction and translate to EPS 
internal format. 

Poll EDI mailbox hourly if not done via PO transactions. 

Execute utility to access Advantis's mailbox using 
IEBASE 

Upload EPS-generated EDI to VAN. 
Download any waiting EDI message. 
Directory browsing. 

PO lookup, browsing and merge update. Look up and 
browse archived PO files. 
PO/EDI error logging. 

Reports all errors and alerts system operator for attention 

in the event of a major error taking place. 
Logs problems to a flat file. 
Event tracking and logging. 
Catalog tools linking for 832 transactions. 
Archiving POs to multiple customer/vendor file systems. 
What is claimed: 

1. A system for electronically ordering items within an 
enterprise comprising: 

a maintenance entity, located outside said enterprise, for 



10 



representing a customized electronic catalogue from 
said master catalogs, over a computer network, said 
maintenance entity comprises; 

means for constructing said customized catalog from said 
master catalogs; 

means for receiving a supplier's price and catalog avail- 
ability changes from a plurality of said distributors and 
propagating them to one or more selected buyers over 
said computer network; 
means for receiving catalog changes from a plurality of 
said catalog content providers and propagating them to 
one or more selected buyers over said computer net- 
work; 

one or more computer systems, maintained by said main- 
tenance entity, and having means for creating and 
transmitting to a plurality of shadow catalog servers 
within said enterprise, images and text of a plurality of 
catalog items offered by said content provider and price 
and availability data from said suppliers; said enterprise 
comprises: 

a plurality of first end-user computer systems geographi- 
cally distributed throughout said enterprise comprising 
a user interface and able to access disk storage on said 
shadow catalog server, and having means for electroni- 
cally ordering said catalog items from said shadow 
catalog servers; 
said shadow catalog servers, which comprise a second 
computer system whose disk storage can be accessed 
over a local area network by one or more first end- 
user's computers; said disk storage being used to hold 
and maintain (1) one or more customized electronic 
catalogs, and (2) internal program code comprising a 
Catalog Browser capable of transmitting purchase 
orders to a master buyer and server, and having means 
for allowing an end user to view said customized 
electronic catalog in order to facilitate comparisons 
between catalog items from several suppliers, and in 
permitting orders to be generated containing items from 
several suppliers; 
said master buyer server comprising a third computer 
system located within said enterprise containing (1) 
purchase order workflow software comprising an order 
manager and a purchase order workflow which takes 
purchase orders from one or more end user computers 
and controls their flow through said enterprise's busi- 
ness processes before transmitting them over a network 
to the supplier; and (2) a Purchase Order data base; and 

means for said master buyer server to receive information 
from and transmit information to said supplier. 

2. A system according to claim 1, further comprising a 
means for specifying, subscription information comprising a 

55 mapping between a plurality of supplier's catalog items and 
one or more buyers for indicating which catalog items can 
be propagated to each buyer's catalog server, where said 
mapping is unique to each said buyer's catalog server. 

3. A system according to claim 1, further comprising a 
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receiving price and availability data from a plurality of 60 means for specifying, pricing information comprising a 



distributors and means for receiving and processing 
images and text of catalog data from a plurality of 
catalog content providers for creating and maintaining 
one or more electronic master catalogs in a central 
location for subsequent distribution to a plurality of 65 
shadow catalog servers distributed throughout said 
enterprise, where said shadow servers contain data 



mapping between a plurality of supplier's catalog items and 
one or more buyers for indicating which catalog items can 
be propagated to each buyer's catalog server, where said 
mapping is unique to each said buyer's catalog server. 

4. A system according to claim 1, further comprising an 
EDI gateway wherein EDI transactions between one or more 
distributors and said maintenance entity are converted to 
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pricing, catalog availability and purchase order transactions 
between one or more customers and said maintenance entity, 
and wherein EDI transactions between one or more suppliers 
and said maintenance entity are converted to catalog update 
transactions between one or more customers and said main- 
tenance entity. 

5. A system according to claim 1, further comprising a 
means for enabling said purchase order workflow software 
to be mapped to the business processes of an enterprise. 
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6. A system according to claim 1, further comprising 
mapping tables constructed by said maintenance entity for 
identifying suppliers, manufacturers, content providers, 
catalogs, catalog items and buyers for uniquely identifying 
5 each, whilst allowing said suppliers, manufacturers, content 
providers and buyers to continue to use the naming conven- 
tions established within their organizations. 

***** 
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METHOD AND APPARATUS FOR 
MAINTAINING AND CONFIGURING 
SYSTEMS 

BACKGROUND OF THE INVENTION 

1. Field of ihe Invention 

This invention relates to maintaining and configuring 
systems. 

2. Background Art 

A system is comprised of components. Before a system 
can be built the components of the system must be identified. 
To configure a system, a user must select the parts to include 
in the system. Typically, one who is knowledgeable about a 
system and its components defines the system. Thus, for 
example, an automobile salesperson assists an automobile 
buyer in determining the type and features of the automo- 
bile. The salesperson understands the features and options 
that are available to create a valid configuration. Some 
features and options cannot be combined. The selection of 
some features caused other features to be unavailable, etc. It 
would otherwise be difficult for the buyer to identify all of 
the features and options available on the automobile that can 
be combined to create a valid configuration. 

Computer systems have been developed to assist one in 
configuring a system. However, these systems use a con- 
figuration language to define a system. Like a programming 
language, a configuration language uses a syntax that must 
be understood by a user who is maintaining the data (i.e., a 
data maintainer). To use one of these configuration systems, 
it is necessary for a data maintainer to understand the 
configuration language. This limits the number of users who 
are able to use the configuration systems. That is, the level 
of sophistication needed to communicate with the configu- 
ration system (through a configuration language) results in 
less sophisticated users being unable to use the system. 

In addition, configuration systems impose a flow or order- 
ing to the user operations. For example, a user is required to 
remove components from the system in reverse of the order 
in which they were chosen. Thus, a user may be forced to 
remove components that the user wants to keep in the 
configuration to remove an unwanted component. A novice 
user may have perform many removal operations before 
achieving an acceptable configuration. If the novice user is 
required to remove components in a preset order, the user 
can become frustrated or confused and abort the configura- 
tion process. 

These systems are designed for a more sophisticated user 
that has knowledge of the system that is being configured as 
well as the configuration system used to configure the 
system. A end user such as an automobile shopper would 
have difficulty using these systems. 

Further, to use these systems a user must be trained to 
understand the configuration language. Thus, a user who 
otherwise has knowledge of the systems that are being 
configured must undergo training to be able to use these 
configuration systems to configure systems. This leads to 
increased expenditures such as for training. 

SUMMARY OF THE INVENTION 

The invention provides the ability to interactively select 
and configure a product among a set of related products 
based on availability and compatibility of features and 
options. It does not impose an order in the selection of 
products, features or options; only valid selections can be 
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made al any time. To create an electronic representation of 
the product information to achieve the above goal, the 
invention provides a framework for defining a product line. 
A product line is defined as a set of related products. A 

5 product line has a set of products that contain parts, or 
components. Parts used to define a product are selected from 
a parts catalog. Parts in a product definition are related or 
classified as: included (parts that are included by default), 
required choices (a choice among a group of parts that must 

10 be made to achieve a valid configuration), optional (parts 
that can be optionally included in the configuration). 

Relationships can be defined between *.hc parts in a 
product definition. A relationship relates a firs) set of parts 
with a second set of parts. A set can include multiple parts. 

15 The incorporation of parts in a set can be arbitrary. That is, 
a multi-part set can contain parts that are otherwise unre- 
lated. For example, a set can contain parts such as an engine, 
sun roof and a color. These parts seem to be unrelated, 
however, it is possible to combine them into a relationship 

20 set for purposes of forming a relationship using the present 
invention. 

Preferably, the part relationships are: included, excluded, 
removed, and requires choice. An included part is included 

25 automatically. A part is excluded from the configuration 
when its inclusion would result in an invalid configuration. 
A part may be removed when another part is added. Thus, 
when a first part exists in the configuration and a second part 
is added, the first part is removed from the configuration. 

3Q The requires choice relationship is used to allow a set of 
choices to be made from a group of parts. The number of 
parts chosen is limited to a valid bounds specification. The 
relations that are created between parts within a product are 
enforced only on that particular product. However, if some 

35 part-to-part relationships are to be enforced on all products 
within a product line, then the relations are generated once 
and enforced for all products. 

A maintenance system is used to define a product. Using 
the maintenance system, a product can be defined using the 

40 product classifications and the part relationships. A graphical 
user interface (GUI) is used to allow the user to interactively 
generate a definition. Instead of configuration languages, 
GUI operations such as drag and drop and selection opera- 
tions can be used to specify a definition. The notions of 

45 included, optional and required choice are easily compre- 
hensible to a user. Further, the idea that parts have interre- 
lationships is also easily understood. Thus, a product can be 
defined without having to learn a complicated configuration 
language. 

50 A configuration system is used to configure a system 
using a definition created by the maintenance system. The 
configuration system ensures that the current configuration 
state is always valid. The user can select and unselect parts 
in any order. When user input is received, the configuration 

55 system validates the input based on the current state of the 
configuration. In addition, the configuration system identi- 
fies selections that could cause a valid configuration to 
become invalid. The configuration removes these selections 
from the set of possible selections so that the user does not 

60 make an invalid selection. 

The configuration system evaluates the current state of a 
configuration based on the product definition, part relation- 
ships and state information. After receipt of input from a 
user, the configuration system evaluates relationships in both 

65 the forward and backward direction. Forward and backward 
evaluations can result in the addition or deletion of elements 
from the configuration. 
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The invention uses both an external and internal repre- 
sentation of a definition or definitions. A translation mecha- 
nism is used translate an external representation into an 
internal representation. The external representation uses a 
conceptually understandable set of relationships for defining 5 
a system and the relationships between the components of 
the system. The invention takes the definition created by a 
user and supplements and compresses the definition when 
necessary to create an internal representation. The internal 
representation is used during configuration to initialize and 10 
validate a configuration based on user input. 

During configuration, the invention maintains runtime 
information that is stored in tables and vectors. To achieve 
greater processing efficiency, the systems represents ele- 
ments in a configuration (e.g., product, part, and group) as 15 
a bit in a bit vector. Thus, for example, a vector has a length 
that is equal to the total number of elements. An element's 
bit can be set or reset to specify the state of the element in 
the current configuration. For example, a user vector can be 
used that specifies for each element whether the element has 20 
been selected by the user during the configuration. In 
addition, excluded and removed vectors identify whether an 
element is excluded or removed (respectively) from a con- 
figuration. Vectors can be used to identify whether an 
element 1) has been selected (by the user or the oonfigura- 25 
tion system), 2) is selectable, and 3) notSelectable. 

Tables contain element relationships. A table is used to 
represent the includes, excludes, removes, and requires 
choice relationships, for example. Each table has a left-hand 
side and a right-hand side that corresponds to the left-hand 3 
and right-hand sides of a relationship. In each case, the 
left-hand side is a bit vector that contains bits that corre- 
spond to elements. The includes, excludes and removes 
tables contain a bit vector in the right-hand side that repre- ^ 
sents configuration elements. The right-hand side of the 
requires choice table is a pointer that points to an entry in a 
group table. The group table entry is a bit vector that 
identifies the elements that are contained in the group from 
which a choice is to be made. The right-hand side of a 
requires choice table entry further includes minimum and 
maximum designations. Minimum and maximum values 
identify the minimum and maximum number of group 
members that are to be selected to satisfy a requires group 
relationship. 

45 

A bit vector implementation of relationships and internal 
runtime state allows for fast and efficient computation of 
relationship based configuration. A comparison of bits can 
be performed in one machine instruction in most cases. 

BRIEF DESCRIPTION OF THE DRAWINGS 5C 

FIG. 1 provides an illustration of a computer system that 
can be used with the invention according to an embodiment 
of the invention. 

FIG. 2 provides an overview of the maintenance and 55 
configuration systems according to an embodiment of the 
invention. 

FIG. 3 illustrates examples of elements in a parts catalog 
according to an embodiment of the invention. ^ 

FIG. 4 illustrates relationships between parts according to 
an embodiment of the invention. 

FIG. 5 provides an example of product classifications 
according to an embodiment of the invention. 

FIG. 6 provides an example of a GUI screen used in 65 
maintenance system 202 according to an embodiment of the 
present invention. 
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FIG. 7 provides an block diagram illustrating the conver- 
sion process according to one embodiment of the invention. 

FIGS. 8A-8B illustrate components of internal represen- 
tation 706 according to an embodiment of the invention. 

FIG. 9 provides a process flow for processing a user 
selection according to an embodiment of the invention. 

FIG. 10 provides an example of a relationship evaluation 
process flow according to an embodiment of the invention. 

FIG. 11 provides an example of an unselect item process 
flow according to an embodiment of the invention. 

FIG. 12 provides a flow for translation processing accord- 
ing to an embodiment of the invention. 

FIGS. 13A-13B provide an illustration of groups and 
nested groups according to an embodiment of the invention. 

FIGS. 14A-14B provide an includes chain process flow 
according to an embodiment of the invention. 

FIGS. 15A-15B provides an example of a subgroup 
excludes process flow according to an embodiment of the 
invention. 

FIGS. 16A-16C provide an example of a relationship 
factorization process flow according to an embodiment of 
the invention. 

FIGS. 17A-17B provide an illustration of a relationship 
compression process flow according to an embodiment of 
the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

A method and apparatus for maintaining and configuring 
systems is described. In the following description, numerous 
specific details are set forth in order to provide a more 
thorough description of the present invention. It will be 
apparent, however, to one skilled in the art, that the present 
invention may be practiced without these specific details. In 
other instances, well-known features have not been 
described in detail so as not to obscure the invention. 

The present invention can be implemented on a general 
purpose computer such as illustrated in FIG. 1. A keyboard 
110 and mouse 111 are coupled to a bidirectional system bus 
118. The keyboard and mouse are for introducing user input 
to the computer system and communicating that user input 
to CPU 113. The computer system of FIG. 1 also includes a 
video memory 114, main memory 115 and mass storage 112, 
all coupled to bi-directional system bus 118 along with 
keyboard 110, mouse 111 and CPU 113. The mass storage 

112 may include both fixed and removable media, such as 
magnetic, optical or magnetic optical storage systems or any 
other available mass storage technology. Bus 118 may 
contain, for example, 32 address lines for addressing video 
memory 114 or main memory 115. The system bus 118 also 
includes, for example, a 32-bit DATA bus for transferring 
DATA between and among the components, such as CPU 
113, main memory 115, video memory 114 and mass storage 
112. Alternatively, multiplex D ATA/address lines may be 
used instead of separate DATA and address lines. 

In the preferred embodiment of this invention, the CPU 

113 is a 32-bit microprocessor manufactured by Motorola, 
such as the 680X0 processor or a microprocessor manufac- 
tured by Intel, such as the 80X86, or Pentium processor. 
However, any other suitable microprocessor or microcom- 
puter may be utilized. Main memory 115 is comprised of 
dynamic random access memory (DRAM). Video memory 

114 is a dual-ported video random access memory. One port 
of the video memory 114 is coupled to video amplifier 116. 
The video amplifier 116 is used to drive the cathode ray tube 
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(CRT) raster monitor 117. Video amplifier 116 is well known 
in the art and may be implemented by any suitable means. 
This circuitry converts pixel DATA stored in video memory 
114 to a raster signal suitable for use by monitor 117. 
Monitor 117 is a type of monitor suitable for displaying 
graphic images. 

The computer system described above is for purposes of 
example only. The present invention may be implemented in 
any type of computer system or programming or processing 
environment. 

The invention maintains and configures systems. The 
invention eliminates the need for a user to learn a configu- 
ration language or write code to maintain and/or configure a 
system. A user interface uses various operations such as drag 
and drop and item selection to define a product, for example. 
Elements that comprise a definition (e.g., of a product) can 
be added or removed in any order. No order is imposed on 
the user. There is no requirement, for example, that the user 
remove parts of a product in the order in which they were 
added. No fixed flow or order is required to edit a given 
product. 

A definition includes an identification of the components 
that comprise the definition and the interrelationships 
between the components. The interrelationships are concep- 
tually easy for the user to understand. The same relation- 
ships are used to define and configure any system. An 
external representation that includes these relationships 
allows a user to view and maintain the definition. The 
external representation is translated into an internal repre- 
sentation that is designed to decrease processing time and 
increase response time. 

In addition, during a configuration session, the invention 
is capable of allowing a user to select or unselect configu- 
ration items without imposing a flow on the user. There is no 
order imposed on the user in terms of the sequence in which 
items are selected for the configuration or unselected from 
the configuration. For example, it is not necessary to select 
a product before choosing options. The invention can iden- 
tify the products that are still available based on the options 
that have already been selected. Further, a user can unselect 
an item (e.g., delete the item from the configuration) without 
regard to the order in which it was selected (e.g., added to 
the configuration). 

Examples of systems that can be maintained or configured 
using the invention include automobiles, computers, time 
clock machines, and shoes. Terms such as part, product line, 
parts catalog, and product are used herein for illustration 
purposes. It should be apparent that this invention can be 
used to configure systems that are not limited to products 
and product lines, etc. 

FIG. 2 provides an overview of the maintenance and 
configuration systems according to an embodiment of the 
invention. Maintenance system 202 maintains a parts cata- 
log 204, parts relationships 206 and product definitions 208. 
Maintenance system 202 uses a user interface that includes 
the ability to add items to parts catalog 204 and specify part 
relationships 206 and product definitions 208. The user 
interface displays a set of hierarchies that provide a con- 
ceptually easier way of viewing a definition. The invention 
maps the set of hierarchies (an external representation) to an 
internal representation. 

The internal representation is used by configuration sys- 
tem 212 to maintain and configure systems based on user 
input. Configuration system 212 provides the ability to 
specify a product. Configuration system 212 verifies the 
product specification. Using configuration system 212, a 
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user can interactively select and configure a product among 
a set of related products based on availability and compat- 
ibility of features and options. It does not impose an order 
in the selection of products, features or options. The con- 

5 figuration system 212 allows the user to only make valid 
selections. However, selections can be made in any order. 

Parts catalog 204 consists of parts that are components of 
products. Similar parts are grouped together to form a part 
hierarchy. Easy maintenance of relationships is achieved by 

10 the hierarchy. For example, when a group of parts is 
assigned a behavior, all the members inherit that behavior 
automatically. FIG. 3 illustrates examples of elements in a 
parts catalog according to an embodiment of the invention. 
Referring to FIG. 3, a parts catalog (e.g., parts catalog 204) 

15 contains parts 302-310, 316, and 318. A parts catalog can 
also contain a group of parts such as group 312. Group 312 
contains parts 306-310. A group can contain other groups. 
For example, group 314 contains group 312 and parts 
316-318. Behavior assigned to elements of group 314 is 

20 inherited by members of group 312. 

Part-to-part relationships can be created between parts 
within a product. Relationships are defined between a first 
set of parts and a second set of parts. During configuration, 
when all of the members of the first set of parts are selected, 

25 the relationship between the two sets is enforced on the parts 
in the second set. In the preferred embodiment, there are four 
kinds of relationships between parts: requires choice, 
includes, can't work with (or excluded), and removes. FIG. 
4 illustrates relationships between parts according to an 

30 embodiment of the invention. 

Part 402 includes part 404. The includes relation causes a 
set of parts in a second set (e.g., part 404) to be included in 
the configuration when a first set of parts (e.g., part 402) is 

35 selected. For example, a luxury package includes a CD 
player; when the luxury package is selected, a CD player is 
included in the configuration. The can't work with (or 
excluded) relation ensures that a set of parts from a second 
set are never in the same configuration as parts in the first 

4Q set. For example, part 402 (e.g., sun roof) can't work with 
part 406 (e.g., a roof-top antenna). When part 402 is 
selected, part 406 cannot be selected. Part 406 is excluded 
such that it cannot be selected. 
When part 402 is selected, part 414 is removed from the 

4S configuration. The removes relation causes items that are 
included in a second set of to be removed from the con- 
figuration when the left side is selected. For example, when 
a high end stereo is selected the standard stereo is removed 
from the configuration. 

50 The requires choice relation recognizes that a choice 
(between a minimum and maximum number) has to be made 
between a second set of parts (or members of a group) to 
ensure a valid configuration when the parts in a first set are 
selected. Part 406 (e.g., climate control feature) requires that 

ss a choice be made among parts 408-410 (e.g., 1 zone A/C or 
2 zone A/C). A requires choice relationship requires that a 
number of items be selected based on minimum and maxi- 
mum values from the right-hand side of the relationship to 
satisfy the relationship. 

60 Parts 408 and 410 can be combined to form group 416. 
Group 416 can be defined by the user. If the user does not 
define group 416, the invention preferably creates group 416 
to contain parts 408 and 410. Thus, when two or more parts 
are defined on the right-hand side of a requires choice 

65 relationship, the invention preferably creates a group that 
contains these parts. The requires choice then becomes a 
requires choice on the group (e.g., group 416). 
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Parts are used to illustrate relationships in FIG. 4. ure a system defined in maintenance system 202. Parts 

However, a relationship can contain groups. To illustrate, a catalog 204 uses a database or other type of storage and 

group of parts can be substituted wherever a part is used in retrieval capability, for example, to store information about 

the illustration. Thus, for example, parts 402, 404, 406, 408, its parts (e.g., part number, description, price, etc.). 

410, and 414 can each be replaced by a group of parts. Thus, 5 The GUI screen of FIG. 6 is divided into a product 

for example, if parts 402 and 404 are replaced by groups definition section 650 and a part relationship definition 

(e.g., groups 402 and 404, respectively), when the members section 652. Pane 602 displays elements from parts catalog 

of group 402 are selected, the members in group 406 are 204. Panes 604, 606, 608 are used to define a product. Panes 

included in the configuration. To further illustrate, part 408 604, 606, and 608 represent classifications or product rcla- 

can be replaced by group 408. In that instance, group 408 is 10 tionships. Panes 610 and 614 and relationship 612 are used 

a member of group 416. A hierarchy of groups (e.g., group to define part relationships. 

408 contained within group 416) can be used in a relation- A user can drag elements from pane 602 to panes 604-608 

s hip to define a product. For example, to include Part B in the 

Parts can be combined to form an arbitrary grouping. definition, Pan B is dragged from pane 602 to pane 

Thus, it is not necessary to combine parts in a group based » 604. Alternatively, to drag parts B, C, IV and E, group Acan 

on a logical or intuitive relationship between the parts in the be dragged from pane 602 to pane 604. Group A and its 

group. For example, a group can contain an engine, a color. component parts (parts B, C, D, and E) are thereby included 

and a sun roof in the product definition. Similarly, a user can specify that a 

. ... configuration user must choose a part from a group, e.g., 

TDe relations that are created be ween parts within a * y dragging one or more parts or a group into pane 

product are enforced only on that particular product. Xn optional part or group can be identified by dragging 

However, if some parl-to-part relationships are to be * 6Qg If an ^ 

enforced on all products within a product fine then the m knot moved to one of panes 604-608 it is assumed 

relations are created once and are enforced or al products. ^ ^ maintainer wants tQ exclude that dement from the 

Hiese relationships are referred to as global relationships. ^ ^ .. being ^ product . level relalion _ 

A product includes zero or more elements of parts catalog shi Qr classifications (or types) illustrated in FIG. 5 can be 

204. Product definition 208 (see FIG. 2) is generate by defined pancs 60 4_608. 

populating it with its component parts. Product definition A subset of the product-level relationships map to a subset 
208 is generated by population of a product with its com- of thc part relationships. For example, the include and 
ponent parts. The parts within a product are classified as one yQ squires choice product-level relationships map to the same 
of three different types: included parts, required choices, or named part rclationsh i ps ^ dc fi nc d in FIG. 4 and shown in 
optional parts. A part that is not classified as one of these relationships 612). Minimum and maximum values set for a 
types is assumed to be unavailable in that product. FIG. 5 rC quires choice product-level relationship map to the mini- 
provides an example of product classifications according to mum and max i mum values of a requires choice part rela- 
an embodiment of the invention. 35 tionship. Elements that are not dragged into one of panes 

An included part is a part that is included in a product by 604, 606 or 608 are considered to be excluded, 

default. For example, parts 504 and 506 are automatically i n addition to defining the elements (and their types) that 

included in product 502. for example, when a configuration comprise the product, the maintainer can specify relation - 

user chooses the product definition product 502, the parts sn ips between parts of the product. Panes 610 and 614 and 

504 and 506 are automatically included in the configuration. 4 o relationship 612 are used to define relationships between 

A required choices classification specifies that a choice partSi jhe maintainer can drag an element (or elements) 

among a group of parts has to be made to create a valid from pane 602 into pane 610, For example, the user can drag 

product configuration. For example, product 502 (e.g., Part N from pane 602 into pane 610. The elements) dragged 

automobile) can include a color group 518 containing red m t 0 pane 610 are referred to as the left-hand side of the 

(part 508), green (part 510) and blue (part 512) that is a 45 relationship. The element (or elements) from pane 602 that 

required choice. In configuring a product, the user must jg related to the left-hand elements) is dragged into pane 

choose a color in this group to create a valid product 614. The elements) dragged into pane 614 are referred to as 

configuration. Parts 514 and 516 are optional parts. An the right-hand side of the relationship. For example, the user 

optional part is not required for a valid configuration. can drag Part K from pane 602 to pane 614. 

A product line is defined as a set of related products. The 50 To identify the type of relationship that exists between the 

invention provides the framework for defining a product left-hand side and right-hand side elements, the maintainer 

line. To define a product line: all parts (components) in the chooses one of the four part-to-part relationships from 

product line are entered into parts catalog 204. An instance relationship 612. For example, if the maintainer chooses the 

in products definition 208 is created that identifies parts from includes relationship, the right-hand side elements are 

parts catalog 204 that are assigned to a product. Part 55 included in the product when a configuration user selects the 

relationships 206 can also be defined for the product. left-hand side element(s). Thus, for example, Part N includes 

Maintenance System Part K. When Part N is chosen by a configuration user, Part 

Parts catalog 204, part relationships 206, and product K is automatically included in the configuration, 

definition 208 are created and maintained using maintenance When the maintainer completes the product definition 

system 202. While any method can be used for creation and 60 using the GUI screen, the product definition is saved (e.g., 

maintenance, a graphical user interface (GUI) is preferably in parts definition 208). The product definition can then be 

used. A text editor could also be used for data entry, for used by a configuration user in configuration system 212. 

example. FIG. 6 provides an example of a GUI screen used External and Internal Representations 

in maintenance system 202 according to an embodiment of The GUI screen of FIG. 6 illustrates a view of a product 

the present invention. One who uses the GUI screen (a 65 as seen by a user (e.g., maintainer and configuration user), 

maintainer) can define a product (e.g., an automobile). A A view of the product that is seen by a user is referred to as 

product definition is used by a configuration user to config- the external representation. A user sees a product or product 
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definition from a conceptual level that is easy to understand. 
The user does not need to express a definition or configu- 
ration using a language that has a syntax that is foreign to the 
user. A GUI having graphical selections and operations is 
preferably used to allow the user to see the external repre- 
sentation. The external representation uses terminology that 
is familiar or intuitive to the maintainer. For example, an 
include product relationship defines elements that can be 
included in a product. 

An external representation seen by the user is translated 
into an internal representation that can be used by the 
invention to process user input. FIG. 7 provides a block 
diagram illustrating the conversion process according to one 
embodiment of the invention. Compiler 704 is used to 
perform the conversion. Compiler 704 generates internal 
representation 706 from external representation 702. 

External representation 702 is the representation of a 
product definition that is created using the maintenance 
system of the invention. External representation 702 pro- 
vides a graphical representation of a system definition, its 
components and their interrelationships. FIG. 6 can be used 
to display external representation 702, External representa- 
tion 702 can include a multi-level hierarchy of parts that help 
to define the product at a conceptual level. The hierarchies 
are not required to drive a configuration session, however. 
Therefore, compiler 704 flattens out the hierarchies. A set of 
relationships is generated using external representation 702 
during a translation process. 

The set of relationships generated for a system definition 
by compiler 704 comprise internal representation 706. Inter- 
nal representation 706 is generated from external represen- 
tation 702 and can be used to control a configuration session. 
In addition to internal representation 706, a configuration 
state is used during the configuration session. FIGS. 8A-8B 
illustrate components of internal representation 706 and the 
configuration slate according to an embodiment of the 
invention. 

Referring to FIG. 8 A, vector 802 provides an example of 
a vector used to store stale information. Vector 802 is 
comprised of bits. A set of p bits is used to represent the 
products that are known to maintenance system 202 and 
configuration system 212. Each bit of the P bits corresponds 
to a product. A set of N bits is used to represent the parts. 
Each bit in the N-bit set corresponds to a part in parts catalog 
204, for example. Vector 802 is therefore P+N bits in length. 

Vectors 804-810 provides implementation examples of 
vector 802. Vectors 804-810 are maintained by configura- 
tion system 212 in a configuration session. Vector 804 is a 
user vector that contains the set of elements that are selected 
by the user. Vector 804 is referred to as the user vector, or 
uVec. The set of elements that are included in the configu- 
ration by the configuration system (e.g., an item that is 
automatically included when the user selects the left-hand in 
an includes relationship) is contained in included vector 806, 
or iVec. Removed vector 808, or rVec, contains the elements 
that are removed from the configuration by configuration 
system 212. Elements excluded from the configuration by 
configuration system 212 are identified in excluded vector 
810, or xVec. 

Each element that can be used to configure a system has 
a bit in these vectors. When an element is included, 
excluded, removed (or deleted), or selected, the correspond- 
ing bit in the appropriate vector (iVec, xVec, rVec, or uVec) 
is set. The use of vectors to represent elements results in 
increased efficiency in processing. Bit-wise operations can 
then be used during processing. For example, it is possible 
to determine whether a group of elements have been selected 
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by the user by performing a bit comparison using the uVec. 
The increased efficiency results in optimal response times 
that are necessary for an interactive system such as is 
preferred for configuration system 212. The bit vector imple- 
mentation used by the invenlion allows for fast and efficient 
computation of runtime algorithms. A bit vector implemen- 
tation of relationships and internal runtime state allows for 
fast and efficient computation of relationship based configu- 
ration. 

Another vector that contains state information is required 
groups vector 812, or rgVec. The rgVec contains a bit for 
each of the required groups specified for a product. As 
previously discussed, the maintainer can include a required 
group in a product definition by dragging a group from pane 
602 to pane 606, for example (see FIG. 6). The number of 
bits in rgVec can differ from the number of bits in vectors 
802-310. The number of bits contained in rgVec corre- 
sponds to the total number of required groups defined for a 
product. Each bil in rgVec is set to indicate that it has not yet 
been satisfied. It is unset (set to zero) when a required group 
has been satisfied. Thus, when a user attempts to accept a 
configuration, configuration system 212 can determine 
whether all of the required choices have been satisfied. 

In addition to these vectors, additional vectors are used to 
determine a current state. The current state is defined by 
three types of state information that track the state of parts 
in the configuration. The current state is visible to the user. 
The three state types are: selected, selectable, and notSe- 
lectable. The selected state identifies all of the parts that are 
currently included in the configuration. The selectable state 
identifies the parts that are not in the configuration but that 
can be selected by the user for the configuration. The 
notSelectable state identifies the parts that are not in the 
configuration and cannot be selected by the user. Configu- 
ration system 212 ensures that only parts that can form a 
valid configuration are selectable; those that cannot are 
notSelectable. 

The uVec, iVec, xVec, and rVec vectors can be used to 
generate the three visible states. The stales are dynamic and 
can change based on user input. The following provides 
definitions using the formulae that can be used to generate 
Ihe three visible stales (+is union and-is difference): 

Sclectcd-(u\fcc+(Vcc)-rVcc 
NotSelectable-* Vec+rVec 
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Selectable-{AllUcm&]-Setected-NotSelecUble 

Computation of the visible state using C++, for example, 
can be accomplished using the following C++ code (the 
syntax assumes appropriate bit -wise operator overloads for 
the given operations): 

SclcctcdVcc«(«Vcc|iVcc)&-/'Vcc 

NotSel ectable Vec-xVec|rVec 

Selectable Vec— (SelcctcdVec|NotSelectableVec) 

The selected state is the union of the elements selected by 
the user or automatically included in the configuration minus 
ihe elements removed by configuration system 212. The 
notSeletable state is the union of the elements that are 
excluded or removed. The selectable state is the set of all 
elements minus the elements already selected and the ele- 
ments that cannot be selected. The selected, selectable, and 
notSelectable states can be generated from these four vectors 
when needed. They can be stored as vectors that have the 
structure of vector 802. 
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Runtime tables are preferably used to store internal rep- 
resentation 706 for a configuration session. FIG. 8B pro- 
vides an example of runtime tables. Runtime table 822 
provides an example of a runtime table. Runtime table 822 
can be used to store relationship information. Runtime table 5 
822 has left-hand side 824 and right-hand side 826. Left- 
hand side 824 contains the left-hand side of a relationship 
(e.g., includes, removes, can't work with or excludes). The 
right-hand side of a relationship is stored in right-hand side 
826. 10 

Table 828 provides an example of runtime table 822. 
Table 828 can be an includes, excludes, or removes table, for 
example. Left-hand side 830 contains a bit vector (i.e., 
"01010 . . . 0"). Right-hand side 832 contains a bit vector 
(i.e., "10001 . . . 1")- Each bit in bit vectors 830 and 832 
corresponds to an element in parts catalog 204 or a product. 15 
For example, if the product definition is for an automobile, 
each "1" bit in bit vector "01010 ... 0" corresponds to a part 
in parts catalog 204 that is contained in an automobile's 
product definition. Zero bits indicate that the part is not 
included in the product definition. With reference to bit 20 
vectors, parts can be identified by the position of their 
corresponding bit in the bit vector. For example, the part 
(that corresponds with the "1" bit in the bit vector "0010" is 
part number three. 

If table 830 is an instance of an includes table, when parts 25 
designated on left-hand side 830 (e.g., part numbers two and 
four) are selected, configuration system 212 includes the 
parts designed in right-hand side 832 (e.g., part numbers one 
and five). Similarly, if table 830 is excludes (or can't work 
with) table, parts one and five are excluded from the 30 
selectable parts when parts two and four are selected. Parts 
one and five are removed from the configuration when parts 
two and four are selected. 

Like the includes, excludes, and removes tables, the 
requires choice table contains a left-hand side and a right- 35 
hand side. In one embodiment, both sides of the requires 
choice table contains a bit vector that corresponds to ele- 
ments in parts catalog 204. Thus, for example, when 
selected, the part(s) identified on left-hand side 836 require 
a choice of a minimum and maximum number of parts from 40 
the parts contained on the right-hand side 838. 

Table 822 can be altered to optimize the storage and use 
of information for a required choice table. Table 834 pro- 
vides an example of an altered table 822. Preferably, 
however, right-hand side 838 contains a pointer to a group 45 
table (e.g.. group table 840) that contains a bit vector (bit 
vector 842) that identifies the parts contained in the group. 
An advantage that the latter (altered table 822) format has 
over the former (unaltered table 822) is that it is only 
necessary to define the members of a group once. Each 50 
product definition that includes the group can point to the 
entry in the group table that contains the group definition. 

One relationship table can be used for all products per 
relationship type. That is, a single includes table is used for 
includes relationships for all of the products. Alternatively, 55 
a table can be partitioned for each product. That is, the 
relationships associated with a product are segregated. For 
example, there would be a includes relationship table for 
each product. This has the advantage of only having to 
process only those relationships that exist for the chosen 60 
product. When a product is unselected or not selectable, 
there is no need to process the tables associated with that 
product. The latter alternative is preferable because it lessens 
processing requirements. 

Configuration System 65 

Using configuration system 212, a configuration user can 
configure a system given a product definition (e.g., product 
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definition 208) and part relationships associated with the 
product definition. Configuration system 212 accepts a con- 
figuration user's input and processes it to update the con- 
figuration based on the user's input or notify the user that the 
input is invalid given the current state of the configuration 
and the system definition. Configuration system 212 ensures 
that the current configuration state (determined by the prod- 
uct definition and order-independent user selection) is 
always valid. 
User Selection 

When user input is received by configuration system 212, 
it is processed based on the current configuration state, the 
Ik jduct definition and the parts relationships. FIG. 9 pro- 
vides a process flow for processing a user selection accord- 
ing to an embodiment of the invention. 

At step 902, the user selects item n (e.g., part) preferably 
using a GUI screen. At step 904 (i.e., "n selectable?"), a 
determination is made whether the item is selectable. Thus, 
for example, configuration system 212 determines whether 
the nth bit in the selectable state information is set. If it is 
not, configuration system 212 determines that the item is not 
selectable by the user and raises an error at step 922. 
Processing then continues at step 914 to update the interface 
(if necessary) and return control of the GUI screen to the 
user. Processing of the current input ends at step 916. 

If, however, it is determined at step 904 that the item 
selected by the user is selectable, processing continues at 
step 908 to set the nth bit in uVec 804. At step 910, the 
visible state information is updated as discussed above. At 
step 912, the relationships associated with the product 
definition are evaluated as discussed below. Processing 
continues at step 914 to update the inf srface (if necessary) 
and return control of the GUI screen to the user. Processing 
of the current input ends at step 916. 
Relationship Evaluation 

Relationships associated with items contained in the prod- 
uct definition are evaluated when user input is received. 
Configuration system 212 determines what relationships are 
active and inactive given the user input (at step 912, for 
example). A relationship is active when all the items on the 
left-hand side of the relationship are selected. A relationship 
is inactive until all of the parts on the left-hand side of the 
relationship are selected. 

As previously discussed, relationship tables can be used 
to store the left-hand and right-hand sides of a relationship. 
That is, a relationship can be defined as a pair of bit vectors, 
the lhsVec (left-hand side) and the rhs\fec (right-hand side). 
A relationship is made active if the following expression is 
true: 

SelectedVec & IhsVec—lhsVec 

When a relationship is made active, updating the appro- 
priate state vector (iVec, xVec, or rVec) becomes: 

slate Vec|-rhsVec 

An active relationship causes the configuration state to be 
updated. When an include relationship is activated, for 
example, parts identified on the right-hand side of the 
include relationship are added to the configuration, if they 
are not already included. The state is changed by modifying 
iVec 806. A change in iVec 806 can change other state 
information such as the selected and selectable state infor- 
mation. Parts that are included as a result of the activation 
of the includes relation can result in a ripple effect that 
causes other relationships to become activated. Thus, addi- 
tional state changes can occur as a result of the include 
relationship's activation. 
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To further illustrate, when a requires choice relation The invention ensures that the relaxation process terminates 

becomes active, configuration system 212 includes and by only adding bits to the state. That is, because iVec, xVec, 

excludes items of the given group where applicable: if and rVec all grow through the iteration, the relaxation 

exactly max (maximum number of ) items of the given group process is guaranteed to terminate. 

are selected, the engine excludes all other items in the group 5 FIG. 10 provides an example of a relationship evaluation 

(added into xVec); otherwise, if less than min (minimum process flow according to an embodiment of the invention, 

number of) items of the group are selected and only one At stcp iooq, rgVec is initialized to zero. During the 

valid selection path exists to make exactly min items relationship evaluation, rgVec is regenerated. At step 1004, 

selected, the engine includes (into i Vec) the items that are CQpics of . Vcc> xVfec ^ rVcc arc madc ^ cop j cs arc ^ 

needed (note that these must have been selectable items). 1Q tQ dctcrmioe whethcr rc i axat ion is finished. At step 1006, the 

Configuration system 212 also ensures that no relation- indudes uble dSSOcizted (hc product definit i on is 

ship that will put the configuration into an invalid state can eva i uated in lnc forward direction. Similarly, forward evalu- 

become active (for example: if b is Selected then the a tion is performed on the excluded and removed Ubles. The 

relationship [a] can't work witfc i[b] should not be active) If forward evaIualion performs an "or" operation with the 

a relationship will make a configuration invalid it is made 1S selectedVe c and a specified configuration state vector (e.g., 

notActivateab e. For example, a relation should be made a f()rward evalualion of lhe includes lable performs an "or" 

notActivateable, if: operation with the selectedVec and and the iVec) when the 

1) an includes relationship has excluded (xVEc) parts on left-hand side of the relationship is true. For example, when 
the right-hand side; the j tems that correspond with the "1" bits in left-hand side 

2) a excludes (can't work with) relationship has Selected 20 330 are all selected (i.e., in the selected vector), right-hand 
parts on the right-hand side; side 832 is "or'ed" with the iVec to add the items that 

3) a removes relation has user-selected (uVec) parts on the correspond with the "1" bits in right-hand side 832 to the 
right side; or configuration where a forward evaluation of an includes 

4) a requires choice relation has a group for which relationship is being performed. 

between [min, max] parts can't be Selected. 25 At step 1008, a backward evaluation is performed on the 

In addition to the relationships created by a maintained relationships contained in the includes, excludes, and 

there are some relationships that are dynamically created or removed tables. In a backward evaluation of an include 

deduced at runtime. If a relation becomes notActivateable relationship, the x Vec is examined to determine whether any 

and all but one item from the left-hand side is Selected, then right-hand side items of an include relationship are 

the unSelected item is excluded by the engine. TTiis ensures 30 excluded. If so, selection of all of the left-hand side items 

that the relation will not become active. would result in an invalid configuration state. Therefore, the 

Configuration system 212 evaluates each relationship last remaining left-hand side item (if only one remains) is 
forward and backward. In a forward evaluation, the left- excluded to cause the relationship to never become active, 
hand side of a relationship is examined to determine whether Thus, the relationship is rendered notActivateable. 
all of its parts are included in the configuration. If they are, 35 Backward evalualion of an excluded relationship exam- 
the relationship is considered to be active. An active reta- ines the selectedVec. If a left-hand side item (an item that is 
tionship causes the right-hand side of the relationship to then supposed to be excluded when the relationship becomes 
be evaluated. The evaluation is dependent on the type of active) is selected, selection of all of the left-hand side items 
relationship. An includes relationship causes the parts speci- would result in an invalid configuration state. To ensure 
fied in the right-hand side to be included in the configuration 40 against an invalid configuration state, a left-hand side item 
specification. A removes relationship causes the right-hand is excluded so that the relationship never becomes active 
side parts to be removed from the configuration. An excludes (the relationship is rendered notActivateable). 
relationship cause the left-hand side parts to become notSe- In the preferred embodiment, configuration system 212 
lectable. A requires choice relationship recognizes that a cannot delete, or remove, a user-selected item. The uVec is 
choice has to be made by the user between the set of 45 examined in a backward evaluation of a removes relation- 
right-hand parts. ship. If a right-hand side item is a user selected item, the 

In a backward evaluation, configuration system 212 deter- selection of all of the left-hand side items would result in an 
mines whether a relationship if activated would result in an invalid configuration state. To ensure against an invalid 
invalid state. If so, configuration system 212 takes steps to configuration state, a left-hand side item is excluded so that 
ensure that the relationship cannot be activated. Instead of 50 the relationship becomes notActivateable. 
evaluating the left-hand side first as in the case of a forward At step 1010, backward and forward evaluation is per- 
evaluation, a backward evaluation evaluates the relationship formed on the requires choice table 834. In the backward 
by first examining the right-hand side. If a relationship fails evaluation, a determination is made whether a requires 
the backward evaluation (i.e., its activation would result in choice relationship should become notActivateable. For 
an invalid state), configuration engine 212 takes steps to 55 example, if it is impossible to satisfy a group, then a 
ensure that the relationship cannot become active. For left-hand side item should be excluded to cause the rela- 
example, if a relationship states that part A can't work with tionship to become notActivateable. 
pan B and part B is selected, configuration system 212 In the forward evalualion, rgVec is set and items are 
excludes part A. This ensures that part A cannot be selected included or excluded where appropriate. For example, if the 
and the excludes relationship cannot become active. 60 right-hand side items are within range (within min and max 
Otherwise, a user can select part A which would result in an values for the required choice relationship), then the remain- 
invalid configuration state. ing right-hand side items are excluded. If the only way to 

The invention performs a relaxation over the set of make a requires choice valid is to select the items remaining 
relationships. A relaxation is an iterative process that is on the right-hand side item, configuration system 212 
repeated until a state thai has been defined no longer 65 includes these items. In addition, a requires choice relation- 
changes. That is, relationship evaluation is completed when ship is evaluated to determine whether the right-hand side 
none of iVec, xVec, or rVec are modified during an iteration. items selected are within a valid range. If not, the corre- 
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sponding bit in the rgVec is set. If so, the corresponding bit the relationship is defined in terms of the new item ID. This 

in the rgVec is zeroed. process, referred to as back-linking, is performed at step 

The selected, selectable, and nolSelectable states are 1204. 

updated at step 1012. At step 1014 (i.e., "change in a At step 1206, an include chain evaluation is performed. In 

vector?"), a determination is made whether any of iVec, 5 ™ include chain evaluation, all include relationship chains 

xVec, or rVec were modified during the current iteration of «<= ^ evaluated so that relationship contains all of the 

the relaxation process. If not, a stable state has been P af * tl \ al " e .included in part regardless of whether he 

un, luaAuiuu F iv,w , included relationship is direct (e.g., mentioned in the 

achieved, and processing ends at step 1016 If so. additional relationshi P } Qr Mt J £ mcatiorlcd in anotber 

iterations are needed to complete the relaxation process. re , ationshi P ma , an included „ on the 

Processing therefore continues at step 1002 to initiate a new 10 ^ side) 

iteration. ........ , i , At step 1208, subgroup excludes are evaluated. In this 

In evaluating relationships, it is not necessary to evaluate • u * i *• u- 1 • • 

. . * . . t . r j ui a -j- .* process, active requires choice relationships are evaluated 

a relationship in either the forward or backward direction F " • , . M , . , . . , . r . , t - 

. , V ai i.-u-' where one relationship s right-hand side is a subset of 

once it has become active. Also, when a relationship is . , . , . , K , t * , . . . tU 

. . . i i_ * * i . ,u «i *• u- ,r another relationship s right-hand side. In this case, if both 

notActivateable, there is no need to evaluate the relationship is . *\ *» . . , , . . ' 

. . f , ' . . .... . • „ rt , A/ ,. ; relationships are active, the right-hand side parts that are not 

in the forward direction. When a relationship is notActi- i _i J n i l* r . ■ .* 

i i . , . . r . # . # within the subset are excluded. Relationship factorization is 

vateable and has been excluded, there is no need to evaluate 

. , , , . t . performed at step 1210. Relationship factorizing can create 

in the backward, or reverse, direction. r « • t_- .i. . .*uu - u 

" . . ' * new relationships that ensure proper runtime behavior when 

J^f! j° n . u » more than one item is selected during some iteration. 

FIG. 9 described processing where the user input was an 20 n . . . . . ° . 

. „ - F * , Removing redundancy in relations may cause some rela- 

ltem selection. Configuration system 212 also processes user . , B 7 . , . . 

. . c *u £ * a * Hons to become unnecessary. A relation becomes unneces- 

uiput to unselect an item from the configuration. As previ- ... * • •» • Lt ■ j n j j . 

*\ - , i i i * sary when it contains no items on its right side. Redundant 

ously discussed, an item can be unselected in any order. . 7 . . . . m t b n . , , 

3 . . 4 , . . , relationships are removed at step 1212. Processing ends at 

There is no requirement to unselect items the reverse order r r & 

in which they were selected. FIG. 11 provides an example of 25 ste £ '. . 

an unselect item process flow according to an embodiment _ a f " m ,. n ^ , , - . . , , .... 

- . t . r Relationships can be defined in terms of groups. When a 

of the invention. r . c . , . . . - °. r , . 

At step 1102 (i.e., "selection in uVec?"), a determination 8 rou P on the left-hand side of a relaUonship the 

is made whether the item that is selected for deletion was f° u P 18 «f ^ an 1 em ID » nd b ^ h ^ ve8 , as a , norma, f 1 f m 

i * -i c - i * *u c u . if ' t , n (e.g., part) and the relationship is denned in terms of this 

selected for inclusion in the configuration by the user. It it 30 v & ».f ' . . . . . . r , _ , _ , . . . 

. , . • j *u * *u •* „ * * i * j ■* new item ID. A relationship is denned for each item in the 

is determined that the item is not a user-selected item, r 

processing continues at step 1104 to raise an error. Process- S 11011 ?* 

ing continues at step 1114 to update the GUI (if necessary) ltem includes item ID (of the group) 

and return control to the user. Processing of the current input 11 15 onl y necessary to create this relationship once per 

ends at step 1116 35 8 rau P' regardless of how many times that group appears on 

If it is determined at step 1102 that the item selected for the left side of a relationship. Back-Linking can be used to 

unselection was selected by the user, processing continues at generate relationships in nested groups. FIGS. 13A-13B 

step 1106 to reset the bit in the u Vec that corresponds to the P rovide an illustration of groups and nested groups accord- 

unselected item (i.e., set the bit to zero). This unselects the in 6 t0 an embodiment of the invention. Group 1302 contains 

item from the current configuration. At step 1108, the iVec, 40 two items (g^P 8 and 1306 ) that are nested witnin 

xVec, and rVec vectors are initialized (set to zero). Steps g rou P 1302 - Notation is provided for a group to specify the 

1110, 1112 and 1114 correspond to steps 910, 912, and 914, minimum and maximum bounds for a group. For example, 

respectively, of FIG. 9. Processing ends at step 1116. lhe notation w (0,l)" indicates that between zero and one 

Translation Between Representations ltems in & rou P 1302 are t0 be cnosen - 

To ensure correct runtime behavior of the engine, a 45 ^ ltems contained in group 1302 are also groups that 

potentially incomplete user-defined set of relationships is conlain multi P le items - Grou P s 1304 and 1306 are nest ed 

converted into a set of complete runtime relationship tables. w,thin gK^P 1302 * Two or three of P arts 1 3 08-1312 can be 

The external representation is translated into an internal choscn from Grou P 1304 - ^ to thrce of P arts 1314-1318 

representation. The invention maps the hierarchies con- can bc chosen from Grou P 1306 * 

tained in parts catalog 204 to relationships and maps rela- 50 ^ mvenUon creates a metapart for these groups (groups 

tionships to the runtime tables, for example. 1302-1306). Relationships are then created between the 

As discussed above, compiler 704 performs a mapping S rou P s and thcir members such that items are back-linked to 

between product-level relationships and part-level relation- their P arcnts - FI G- 13B provides an illustration of metaparls 

ships. The translation process further provides the ability to for tne g rou P s and nested g rou P of FIG - 13A according to an 

translate a multi-level hierarchy to a single-level hierarchy. 55 embodiment of the invention. Groups 1302'-1306' are meta- 

That is, the translation process can be used to flatten out the P arts for groups 1302-1306, respectively. Relationships can 

intuitive hierarchy created by a maintenance user using the be generated using these metaparts as follows: 

user interface of FIG. 6, for example. FIG. 12 provides a Group 1302' requires choice [Group 1304\ Group 1306'] 

flow for translation processing according to an embodiment 0j1 

of the invention. 60 Group 1304' requires choice [part 1308, part 1310, part 

At step 1202, a set of relationships is created based on the 1312] 2,3 

hierarchies. Thus, for example, group 312 is translated into Group 1306' requires choice [part 1314, part 1316, part 

an requires choice relationship. That is, group 312 requires 1318] 0,3 

a choice between parts 306, 308, and 310. Relationships can The metapart is used internally; it is unnecessary for a 

be defined in terms of groups. An identifier (item ID) is used 65 user to be aware of them. Using back-linking, relationships 

to identify the group. When a group appears on the left-hand can be generated such that an item (e.g., part 1308) links 

side of a relationship, the group is assigned an item ID and back to its predecessors) (e.g., nested group, group 1302). 
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The following new relationships can be created for the vector, temp, is created that is the result of an "or" operation 
examples of FIGS. 13A-13B: between the left-hand and right-hand sides of r. Another 
Group 1304' includes Group 1302' temporary vector, tempsave is created that is set to the value 
„ • , ^ ,™<i. of temp at step 1412. At step 1414 (i.e., "all rels. 
Group 1306 includes Group 1302 ^ compared?"), a determination is made whether all of the 
Part 1308 includes Group 1304' otrier includes relationships have been evaluated against r. If 
Part 1310 includes Group 1304' not, processing continues at step 1418 to get another 
Part 1312 includes Group 1304' relationship, r 2 . At step 1420 (i.e., "temp hits r 2 ?"), a 
Part 1314 includes Group 1306' determination is made whether any of the items contained m 
r temp are also contained in r 2 . If not, processing continues at 
Part 1316 includes Group 1306 io gtep m4 {Q process any remaining relationships against r. 
Part 1318 includes Group 1306' if so, processing continues at step 1422 to perform a "or" 
When a user selects part 1308, part 1308 includes group operation between temp and the right-hand side of r 2 to add 
1304'. Group 1304' is added to the configuration. Further, the right-hand side of r 2 to the temp vector, 
group 1304' includes group 1302' thereby including group If it is determined, at step 1414, that all of the relation - 
1302'. When group 1302' is included in the configuration, it 15 ships r 2 have been evaluated for r, processing continues at 
activates the relationship that requires a choice between step 1416. At step 1416 (i.e., "temp-tempsave?"), a deter- 
groups 1304' and 1306'. Since group 1304' is already mination is made whether any items were added to the temp 
selected, group 1306' can be excluded. When group 1306' is vector. If not, there are no indirect includes and processing 
excluded, parts 1314-1318 are excluded when the newly continues at step 1424 to reset r 2 and processing continues 
generated relationships are evaluated in the reverse 20 at step 1414 to process any remaining relationships against 
(backward) direction. Further, the bounds specified by group this relationship. If so processing continues at step 1404 to 
1304 are also enforced using these relationships. modl 5> th ? nght-hand side of r to include the items con- 
As discussed above, a requires choice relationship can be \*™* ™ lem P ve p ctor mmus the t ! tems ™ ni ? m iZ ^ 
j c j ,, L t . * | a , . „ • *~ . • ^ left-hand side of r. Processing continues at step 1402 to 
defined at the product leveL A product can require a choice rcmai rclatio ^ 

between items in a group, product-leve I requires choice 25 jf ft ^ &{ ^ (i all mdudc ^ 

relationship is treated similarly to that of a requires choice processed ?») that a n 0 f the includes relationships have been 

part-level relationship. evaluated for include chains, processing ends at step 1404. 

Include Chains Subgroup Excludes 

In an include chain evaluation, all include relationship ^ su5group excludes evaluation is performed on 
chains are fully evaluated so that a relationship can be ™ Kquircs cho ice relationships. Assume a requires choice 
generated that contains all of the parts that are included rclationsh ; p poirjls to a group (A) that is a complete sub- 
regardless of whether the relationship is direct (e g the grQup Qf a grQup (fi) of a[)0(ncr fcquircs choice rclationship- 
included parts mentioned in the includes relationship) or Tf B has a max of X and b^h relationships are made active, 
indirect (a part is mentioned in another includes relationship the Uems in fi that afe nQt in ^ Q camol be choscD , f a 
that contain an included part on the right-hand side). For * 5 pairwise comparison of requires choice relationships yields 
example, the following relationships exists in the external &uch cases> a rclationship such as mc following is generated: 
representation: |- union of Jeft gides of ^ relationships] caa » t work w j tn 



a includes b and c 



Q 



b includes d 4Q For example, assume that the following relationships have 

d and c includes e been defined: 

An include chain exists that starts with a. The first a b requires choice [x, y, z] (0,1) 

relationship indicates that a includes b and c. Based on the ^ requires choice [x, y] (0,2) 

second and third relationships, b and c include other parts. Th e second relationship contains a group that is a sub- 
Based on all of the relationships, a includes b, c, d, and e. 4S gr0U p 0 f tne first relationship. When both relationships are 
Include chain evaluation expands these relationships into the active, the non-subset is excluded. This avoids the case 
following relationships: where a user selects a, b, and d and the relationship evalu- 
a includes b and c and d and e ations do not exclude the items not included in both groups 
b includes d (the non-subset). The invention combines these relationships 
d and c includes e 50 and creates an excludes relationship. The excludes relation - 
It is not necessary to generate additional relationships to ship for the above example is as follows: 
perform includes chain evaluation. Preferably, includes a b d excludes z 

chain evaluation can modify an existing relationship to FIGS. 15A-15B provides an example of a subgroup 

include both direct and indirect includes relationships. Each excludes process flow according to an embodiment of the 

includes relationship can be evaluated against all other SS invention. At step 1502 (i.e., "all rels. processed?"), a 

includes relationships to determine whether its right-hand determination is made whether all of the requires choice 

side should be modified to include both direct and indirect relationships have been processed. If so, processing ends at 

includes relationships. Once all of the includes relationships step 1504. If not, processing continues at step 1506 to get the 

have been evaluated, a new right-hand side value can be next relationship, r. At step 1507 (i.e., "r.rhs.max=17"), a 

generated based on the evaluation. FIGS. 14A-14B provide 60 determination is made whether the maximum value for the 

an includes chain process flow according to an embodiment relationship is equal to one. If not, processing continues at 

of the invention. step 1502 to process any remaining relationships. If so, 

At step 1402 (i.e., "all include rels processed?"), a deter- processing continues at step 1508. At step 1508 (i.e., "all 

mination is made whether all of the includes relationships rels. compared?"), a determination is made whether all of 

have been processed. If other includes relationships remain 65 the other requires choice relationships have been processed 

to be processed, processing continues at step 1408 to get the against r. If so, processing continues at step 1502 to process 

next includes relationship, r. At step 1410, a temporary another requires choice relationship. 
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If not, processing continues at step 1510 to get another made whether the right-hand side of the i relationship and 
relationship, r 2 . At step 1512 (i.e., "r-r 2 ?"), a determination the left-hand side of the r relationship have any bits in 
is made whether the two relationships are equal. If so, common. If they do not have bits in common, processing 
processing continues at step 1508 to process any remaining continues at step 1614 to process any remaining relation- 
requires choice relationships against the current r. If r and r 2 5 ships against the current i. If they do have bits in common, 
are not equal, processing continues at 1514. At step 1514 processing continues at step 1622 to generate new.lhs from 
(i.e., "r2.grp subset of r.grp?"), a determination is made the includes relationship and the left-hand side of r. Step 
whether the right-hand side of r 2 is a subset of the right-hand 1622 takes out items in the right-hand side of i from 
side of r. If not, processing continues at step 1508 to process left-hand side of r and adds in items that are in the left-hand 
any remaining requires choice relationships against the JQ side of i. At step 1624 (i.e., "new.lhs has value?") a deter- 
current r. If so, processing continues at step 1516 to create mination is made whether new.lhs has value. This detcrmi- 
an exclude relationship where the left-hand side is the union nation can use the guidelines as specified above, 
of the left-hand side of r and r 2 and the right-hand side is the if ne w.lhs does not have value, processing continues at 
non-subset of the right-hand side of the two relationships. step 1^14 to processing any remaining relationships against 
Processing continues at step 1508 to process any remaining i. if it does have value, processing continues at step 1626 to 
requires choice relationships against the current r. ^ a new relationship (of the type r) that uses new.lhs as the 
Relationship Factorization left-hand side and the right-hand side of r. The new rela- 
The invention assumes that one item on the left side of a (ionship is marked as "new" at step 1628. The value of added 
relationship is preferably selected during any iteration. & l0 "true" at step 1630. Processing continues at step 
However, the includes and requires choice relationships may 1614 to process any remaining relationships, 
cause additional items to become selected (e.g., selected by Relationship Compression 

the system). Factorizing of relationships can create new Removing redundancy in relations may cause some rela- 

relationships to ensure proper runtime behavior when more ti ons to become unnecessary. A relation becomes unneces- 

than one item is selected during some iteration. sary w hen it contains no items on its right side. If a 

Factorization causes a relationship to be created where a relationship's left-hand side is a proper subset of the left- 
relationship has items on the left-hand side that also appear hand side of another relationship, then the first relationship 
on the right-hand side of an includes relationship. The new & guaranteed to be active whenever the second relationship 
relationship represents the common factorization of both ^ active. If both relationships are also the same type of 
relationships. For example, where the following two rela- relationship, the common right-hand side elements can be 
tionships exist: ^ removed from the second relationship. This can be repeated 

[a] includes [b and c] to remove all unnecessary relationships. The following 

[b and c and d and e] can't work with [x and y] relationships provide an example: 

the following relationship is created: [ a ] removes [c] 

[a and d and e] can't work with [x and y] [ a and b] removes [c and d] 

The invention uses a technique in factorization that avoids 35 The left-hand side of the first relationship is a proper 

combinatorial explosion. Relationships are created during subset of the left-hand side of the second relationship (e.g., 

factorization when they add value. The invention identifies all elements "a" in the left-hand side of the first relationship 

value where the new relationship: are contained in the left-hand side of the second 

1. replaces more than one item from the left-hand side; relationship). The relationships are the same type. Therefore, 

2. has at least two different includes relationships replace 40 the common right-hand side elements can be removed from 
at least one unique item from the left-hand side of the the right-hand side of the second relationship. The following 
relationship being factorized; and is the result after modifying the relationship: 

3. the two includes relationships have at least one com- [a] removes [c] 

mon item in their left-hand side. [a and b] removes [d] 

FIGS. 16A-16C provide an example of a relationship 4S FIGS. 17A-17B provide an illustration of a relationship 

factorization process flow according to an embodiment of compression process flow according to an embodiment of 

the invention. At step 1602, each relationship is marked as the invention. At step 1702 (i.e., "all relationships in table 

"new". At step 1604, a state variable, added, is initialized to processed?"), a determination is made whether all of the 

"false". At step 1606 (i.e., "all includes rels. processed?"), a relationships in the table have been processed. If not, 

determination is made whether all of the includes relation- 50 processing continues at step 1704 to get the next 

ships have been processed. If so, processing continues at relationship, r. At step 1706 (i.e., "r processed against all 

step 1608 (i.e., "added^true'?) to determine whether any other rels. in table?"), a determination is made whether the 

new relationships were added. If not, processing ends at step other relationships in the table have been processed against 

1610. If there are new relationships, processing continues at r. If so, processing continues at step 1702 to process any 

step 1609 to reset the includes relationships and processing 55 remaining relationships in the table as r. 

continues at step 1604 to initialize added to "false". If it is determined at step 1706 that all of the other 

If it is determined at step 1606 that all of the includes relationships have not been processed against r, processing 
relationships have not been processed, processing continues continues at step 1708, Another relationship is retrieved as 
at step 1612 to get the next includes relationship, i. At step r 2 at step 1708. At step 1710 (i.e., w r«r2?") ( a determination 
1613, the relationships are reset. At step 1614 (i.e., "all 'new* 60 is made whether the relationships are the same. If not, 
rels. processed?"), a determination is made whether all of processing continues at step 1706 to process any remaining 
the relationships have been marked as "new" have been relationships against r. If so, processing continues at step 
processed against i. If so, processing continues at step 1606 1712. At step 1712 (i.e., "r.lhs subset of r2.1hs?"), a deter- 
to process any remaining includes relationships. If not, mination is made whether the left-hand side of r is a subset 
processing continues at step 1616. 65 of the left-hand side of r 2 . If the subset condition is true, 

At step 1616, the next relationship, r, is marked as "old". processing continues at step 1714 to remove the common 

At step 1620 (i.e., "!(r,lhs && i.rhs)?", a determination is items out of the right-hand side of r (i.e., perform the 
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operation r 2 .rhs-r 2 .rhs and not r.rhs). Processing continues 
at step 1706 to process any remaining relationships against 
r. 

If it is determined at step 1702 that all of the relationships 
have been processed as r, processing continues at step 1716. 
At step 1716 (i.e., "all relationships in table processed?") a 
determination is made whether all of the relationships have 
been processed. If so, processing ends at step 1718. If not, 
processing continues at step 1720 to gel another relationship 
as r. At step 1722 (i.e., "r.rhs-zeroes?"), a determination is 
made whether the right-hand side of r has been set to zero 
has a result of compression. If not, processing continues at 
step 1716 to p.'.xess any remaining relationships. If so, 
processing continues at step 1724 to delete r from the table. 
Processing continues at step 1716 to process any remaining 
relationships. 
Global Relationships 

Global relationships can be defined that are processed for 
all products. Thus, it is unnecessary to redefining a relation- 
ship for all of the products. The relationship can be defined 
as a global relationship that is applied for every product. If, 
however, partitioned relationship tables are used for each 
product, it is necessary to evaluate the relationships in a 
product's partitioned relationship tables as well as the global 
relationships. For example, the process flows described 
herein that operate on relationship tables can be performed 
once for the product's partitioned relationship tables and 
once for the global relationships. 

Thus, a method and apparatus for maintaining and con- 
figuring systems has been provided. 

We claim: 

1. A method of configuring a system comprising the steps 

of: 

generating a definition for said system, said definition 
containing one or more elements and being conveyed 
graphically using a set of product relationships, said 
product relationships identifying classifications for said 
one or more elements, said product relationships com- 
prising an includes classification; 

generating a set of part relationships between said one or 
more elements, said set of part relationships being 
conveyed graphically; and 

configuring said system using said definition and said set 
of product relationships and said part relationships. 

2. The method of claim 1 wherein said step of configuring 
further comprises the steps of: 

receiving input from a configuration user; 

validating said input based on said definition, said set of 

relationships, and a current configuration state; and 
identifying a set of valid configuration options using said 

definition, said set of relationships and said current 

configuration state. 

3. The method of claim 2 wherein said step of identifying 
further comprises the steps of: 

determining whether a relationship in said set of relation- 
ships is active; 

modifying said configuration to satisfy said active rela- 
tionship when it is determined that a modification is 
needed; 

making said relationship notActivateable when it is deter- 
mined that said relationship is not active and the 
activation of said relationship would render the con- 
figuration invalid. 

4. The method of claim 3 wherein said step of determining 
whether a relationship is active further comprises the step of 
determining whether the elements specified in the left-hand 
side of said relationship are present in said configuration. 
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5. The method of claim 4 wherein said step of determining 
whether the elements specified in the left-hand side of said 
relationship are present in said configuration further com- 
prises the step of performing a bit-level comparison of the 

5 bits corresponding to the elements in said left-hand side of 
the relationship with a "selected" bit vector. 

6. The method of claim 3 wherein said relationship is an 
includes relationship, said step of modifying further com- 
prises the step of including in said configuration elements 

to identified in a right-hand side of said relationship. 

7. The method of claim 3 wherein said relationship is an 
excludes relationship, said step of modifying further com- 
prises the step of marking said elements identified in the 
right-hand side of said relationship as excluded and notSe- 

15 lectable. 

8. The method of claim 3 wherein said relationship is a 
removes relationship, said step of modifying further com- 
prises the step of removing said elements identified in the 
right-hand side of said relationship from said configuration. 

20 9. The method of claim 3 wherein said relationship is a 
requires choice relationship, said step of modifying further 
comprises the steps of: 
determining whether a plurality of elements identified in 
a right-hand side of said relationship are present in said 
25 configuration such that said relationship is satisfied; 
modifying said configuration to satisfy said requires 
choice relationship when it is determined that only one 
path exists to satisfy said relationship and said rela- 
tionship is not already satisfied. 
30 10. The method of claim 3 wherein said step of making 
said relationship notActivateable further comprises the step 
of marking one or more elements in said left-hand side of 
said relationship as notSelectable. 

11. The method of claim 2 wherein said definition, each 
35 of said set of relationships, and said current configuration 

state are expressed as bit vectors having bits that correspond 
to elements. 

12. The method of claim 2 wherein said step of validating 
further comprises the step of determining whether the rela- 

40 tionships other than those marked notActivateable in said set 
of relationships can be satisfied. 

13. The method of claim 2 wherein said step of generating 
a definition selects said one or more elements for inclusion 
in said definition, said input is made without regard for the 

45 order in which said one or more elements are selected for 
said definition. 

14. The method of claim 2 wherein said configuration 
state identifies a set of selected elements and a set of 
selectable elements for said system, said input capable of 

50 selecting any member of said set of selectable elements and 
being made despite the order in which members of said set 
of selected elements were selected. 

15. The method of claim 1 wherein a parts catalog is used 
to store information associated with said one or more 

55 elements, said information including an identifier and 
description. 

16. A method for defining a system that can be configured 
comprising the steps of: 

6Q identifying an element of said system; 

specifying said element as an included element when said 
element is automatically included in the configuration; 
specifying said element as an optional element when said 
element is not a necessary component of said system; 
65 specifying said element as a required choice when said 
element is a group that contains one or more members 
from which to choose. 
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17. The method of claim 16 wherein said element is a computer readable program code configured to cause a 
member of a first element set said first element sel contain- computer to modify said configuration to satisfy said 
ing one or more elements, said method further comprising active relationship when it is determined that a modi- 
ihe steps of: fication is needed; 

identifying a second element set of said system, said 5 computer readable program code configured to cause a 

second element set containing one or more elements; computer to make said relationship notActivateable 

and when it is determined that said relationship is not active 

specifying a relationship between said first element set and lhe activation of said relationship would render the 

and said second clement set. configuration invalid. 

18. The method of claim 17 wherein said step of sped- 10 23 - The article of manufacture of claim 22 wherein said 
fying further comprises the steps of: computer readable program code configured to cause a 

•r • ■ . « j. , 1 j j computer to determine whether a relationship is active 

specifying that said second element set is to be included fill ..ifl, ™ ,• . _ , F . " 

r . J . . & . . . , - . . ... . further comprises computer readable program code confie- 

n said system when said first element set is present in ured t0 cause a com puter t0 determine whether the elements 

said system, specified in the left-hand side of said relationship are present 

specifying that said second element set is to be excluded 15 in said configuration. 

from said system when said first element set is present 24. The article of manufacture of claim 23 wherein said 
in said system; and computer readable program code configured to cause a 
specifying that said second element set is to be removed computer to determine whether the elements specified in the 
from said system when said first element set is present left-hand side of said relationship are present in said con- 
in said system. 20 figuration further comprises computer readable program 

19. The method of claim 16 further comprising the steps code configured to cause a computer to perform a bit-level 
of: comparison of the bits corresponding to the elements in said 

specifying a group of elements; lef i' ha ^ side ?* »«» »lalibnship with a "selected" bit-vector. 

• r . , . . c . , 25. The article of manufacture of claim 22 wherein said 

specifying a relationship between said first element set relationship is an includes relationship, said computer read- 

and said group of elements such that one or more able ^ configured t0 cause F a romputer P to modify 

elements in said group of elements must be chosen ^ tihcr comprises computer readable program code config- 

when said first element set is present in said system. ured (0 cause a m r tQ mdude m said ^ * n 

20. An article of manufacture comprising: e[ements identified in a right . hand side of said rclal t onshi 

a computer usable medium having computer readable 3Q 26. The article of manufacture of claim 22 wherein said 
program code embodied therein for configuring a sys- relationship is an excludes relationship, said computer read- 
tern comprising: ab i e pr0 g ram co de configured to cause a computer to modify 
computer readable program code configured to cause a fu rlhe r comprises computer readable program code config- 
computer to generate a definition for said system, ured t0 cause a computer to mark said elements identified in 
said definition containing one or more elements and 35 the r i g ht-hand side of said relationship as excluded and 
being conveyed graphically using a sel of product notSelectable. 

relationships, said product relationships identifying 2 7. The article of manufacture of claim 22 wherein said 
classifications for said one or more elements, said relationship is a removes relationship, said computer read- 
product relationships comprising an includes classi- able program code configured to cause a computer to modify 
fication; 4Q fu rmcr comprises computer readable program code confie- 
computer readable program code configured to cause a ured t0 ^ a corn p Uter t0 remove said elements identified 
computer to generate a set of part relationships in lhe right-hand side of said relationship from said con- 
between said one or more elements, said set of part figuration 

relationships being conveyed graphically; and 2 8. The article of manufacture of claim 22 wherein said 

computer readable program code configured to cause a 4$ relationship is a requires choice relationship, said computer 

computer to configure said system using said defi- readable prograrn codc configured to cause a t0 

nition and said set of product relationships and said mod jf y f urther comprises: 

->i i?l rt r ^ at *°"f m PS- . - A , * - computer readable program code configured to cause a 

21. THe article of manufacture of claim 20 wherein sa.d lef t0 dtl J mi » whetner ^ » 0 f elements 

cZu Z ,o co a „fiLf e Tr C ° nfigUred ,0 CaUSC " 50 iden ' ified in a W-^* side »f Lid relaL" 

computer to configure further compnses: fa Mid confi tio „ such , hat sajd relation P sni 

computer readable program code configured to cause a j s satisfied" 

computer to receive input from a configuration user; computcr rea ' dable ram ^ ^ (o cause 

computer readab e program code configured to cause a compuler to modif said ranfiguratio * lo satfsf M y 

computer to validate said input based on said definition, 55 requires choice re i ationship when it is determined that 

said set of relationships, and a current configuration orjly onc path exists to Mlisfy said rcUtionship and Mid 

state, and relationship is not already satisfied. 

computer readable program code configured lo cause a 29. The article of manufacture of claim 22 wherein said 

computer to identify a set of valid configuration options computer readable program code configured to cause a 

using said definition, said set of relationships and a 6 o computer to make said relationship notActivateable further 

current configuration state. comprises computer readable program code configured to 

22. The article of manufacture of claim 21 wherein said cause a computer to mark one or more elements in said 
computer readable program code configured to cause a left-hand side of said relationship as notSelectable 
computer to identify further comprises: 3 0. The article of manufacture of claim 21 wherein said 

computer readable program code configured to cause a 65 definition, each of said set of relationships, and said current 

computer to determine whether a relationship in said configuration state are expressed as bit vectors having bits 

set of relationships is active; that correspond to elements. 
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31. The article of manufacture of claim 21 wherein said 
code configured to cause a computer to validate further 
comprises program code configured to cause a computer to 
determine whether the relationships other than those marked 
notActivateable in said set of relationships can be satisfied. 

32. The article of manufacture of claim 21 wherein said 
code configured to cause a computer to generate a definition 
selects said one or more elements for inclusion in said 
definition, said input is made without regard for the order in 
which said one ore more elements are selected for said 
definition. 

33. The article of manufacture of claim 21 wherein said 
configuration state identifies a set of selected elements and 
a set of selectable elements for said system, said input 
capable of selecting any member of said set of selectable 
elements and being made despite the order in which mem- 
bers of said set of selected elements were selected. 

34. The article of manufacture of claim 17 wherein a parts 
catalog is used to store information associated with said one 
or more elements, said information including an identifier 
and description. 

35. An article of manufacture comprising 

a computer usable medium having computer readable 

program code embodied therein for defining a system 

that can be configured comprising: 

computer readable program code configured to cause a 
computer to identify an element of said system; 

computer readable program code configured to cause a 
computer to specify said element as an included 
element when said element is automatically included 
in the configuration; 

computer readable program code configured to cause a 
computer to specify said element as an optional 
element when said element is not a necessary com- 
ponent of said system; 

computer readable program code configured to cause a 
computer to specify said element as a required 
choice when said element is a group that contains 
one or more members from which to choose. 

36. The article of manufacture of claim 35 wherein said 
element is a member of a first element set said first element 
set containing one or more elements, said article of manu- 
facture further comprising: 

computer readable program code configured to cause a 
computer to identify a second element set of said 
system, said second element set containing one or more 
elements; and 

computer readable program code configured to cause a 
computer to specify a relationship between said first 
element set and said second element set. 

37. The article of manufacture of claim 36 wherein said 
computer readable program code configured to cause a 
computer to specify further comprises: 

computer readable program code configured to cause a 
computer to specify that said second element set is to 
be included in said system when said first element set 
is present in said system; 

computer readable program code configured to cause a 
computer to specify that said second element set is to 
be excluded from said system when said first element 
set is present in said system; and 

computer readable program code configured to cause a 
computer to specify that said second element set is to 
be removed from said system when said first element 
set is present in said system. 

38. The article of manufacture of claim 35 further com- 
prising: 
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computer readable program code configured to cause a 
computer to specify a group of elements; 

computer readable program code configured to cause a 
computer to specify a relationship between said first 
5 element set and said group of elements such that one or 
more elements in said group of elements must be 
chosen when said first element set is present in said 
system. 

39. A method of configuring a system comprising the 
10 steps of: 

translating a system definition from an external represen- 
tation comprising a set of intuitive relationships 
between components of said system definition into an 
internal representation comprising a set of internal 
15 relationships; 

validating configuration input using said internal repre- 
sentation; and 

modifying a configuration state based on said user input. 
20 40. The method of claim 39 wherein said step of trans- 
lating further comprises the step of: 
removing a plurality of hierarchical levels from said 
external representation such that said internal represen- 
tation is a single level. 
25 41. The method of claim 40 wherein said step of trans- 
lating further comprises the step of: 
creating a set of relationships based on said hierarchical 
levels, each one in said set of relationships having a 
first set of components and a second set of components 
30 and a relationship operator. 

42. The method of claim 41 wherein said relationship 
operator is chosen from the operators include, exclude, 
remove, and requires choice. 

43. The method of claim 39 wherein each of said internal 
35 relationships has a left-hand side, a relationship operator and 

a right-hand side, said step of translating further comprises 
the steps of: 

determining whether a group of components exists on said 

left-hand side of one of said internal relationships; 
performing the following steps when a group of compo- 
nents exist on said left-hand side: 
creating a new component for said group; and 
creating a new relationship for each component of said 
45 & rou P of components such that each component will 

include said new component. 

44. The method of claim 39 wherein a type of said internal 
relationships is an include relationship, said include rela- 
tionship identifies a second set of components that are 

5Q included in said system when all of a first set of components 
exist in said system, said step of translating further com- 
prises the steps of: 
determining whether a subset of the union of said first and 
second sets of components in a first includes relation- 
55 ship comprises a first set of components in a second 
includes relationship; and 
generating a combined includes relationship, said com- 
bined relationship comprises said first set of compo- 
nents of said first includes relationship and said second 
60 set of components from said first and second includes 
relationships when said subset of the union of said first 
and second sets of components in said first includes 
relationship comprises a first set of components in a 
second includes relationship. 
65 45. The method of claim 39 wherein a type of said internal 
relationships is a requires choice relationship, said requires 
choice relationship identifies a second set of components 
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from which a number of components must be chosen when 
a first set of components exist in said system definition, said 
step of translating further comprises the steps of: 

determining whether a second set of components of a 
second requires choice relationship is a proper subset of 
a second set of components of a first requires choice 
relationship: 

performing the following steps when said condition 
exists: 

creating a new relationship such that said new relation- 
ship excludes a second set of components of said 
new relationship when a first set of components of 
said new relationship is selected, said new relation- 
ship's first set of components is the union of the first 
set of components of said first and second requires 
choice relationships and said new relationship's sec- 
ond set of components is the difference of the second 
set of components of said first and second requires 
choice relationship. 

46. The method of claim 39 wherein a type of said internal 
relationships is an includes relationship, said includes rela- 
tionship identifies a second set of components that are 
included in said system when all of a first set of components 
exist in said system, said step of translating further com- 
prises the steps of: 

determining whether the second set of components of an 
includes relationship are contained in a first set of 
components of another internal relationship; 

replacing said second set of components of said includes 
relationship in said another internal relationship with 
said first set of components of said includes relation- 
ship when said second set of components of an includes 
relationship are contained in a first set of components 
of another internal relationship. 

47. The method of claim 39 said internal representation 
comprises multiple types of relationships, each type of 
relationship having a first and second set of components and 
an operation, said operation is performed on said second set 
of components when said first set of components exist in 
said system. 

48. The method of claim 47 wherein said step of trans- 
lating further comprises the steps of: 

determining whether a first and second relationship are 

the same type of relationship; 
performing the following steps when they are the same 

type: 

determining whether the first relationship's first set of 
components is a proper subset of the second rela- 
tionship's first set of components; 

removing the first relationship's second set of compo- 
nents that exist from the second relationship's sec- 
ond set of components when said proper subset 
exists; 

removing said second relationship when said second 
relationship's second set of components is an empty 
set. 

49. The method of claim 47 wherein said step of validat- 
ing further comprises the steps of: 

determining whether a component selected by said con- 
figuration input is selectable; and 

invalidating said configuration input when said compo- 
nent is not selectable. 

50. The method of claim 49 wherein said one of said 
internal relationships is an includes relationship, said 
includes relationship causing a second set of components to 
be included in said system when all members of a first set of 
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components exist in said system, said second step of deter- 
mining further comprises the step of: 
determining whether any member of the second set of 
components cannot be included in said system. 
5 51. The method of claim 49 wherein said one of said 
internal relationships is an excludes relationship, said 
excludes relationship causing a second set of components to 
be excluded from said system when all members of a first set 
of components exist in said system, said second step of 
10 determining further comprises the step of: 

determining whether any member of the second set of 
components already exists in said system. 

52. The method of claim 49 wherein said one of said 
internal relationships is an removes relationship, said 
removes relationship causing a second set of components to 

15 be removed from said system when all members of a first set 
of components exist in said system, said second step of 
determining further comprises the step of: 

determining whether any member of the second set of 
components has been selected for inclusion in said 

20 

system by a configuration user. 

53. The method of claim 49 wherein said one of said 
internal relationships is a requires choice relationship, said 
requires choice relationship requiring a selection of a num- 
ber of members of a second set of components when all 
members of a first set of components exist in said system, 
said second step of determining further comprises the step 
of: 

determining whether said number of members of said 
3Q second set of components cannot be selected for addi- 
tion to said system. 

54. The method of claim 47 wherein said step of modi- 
fying further comprises the steps of: 

determining whether the performance of said operation of 
35 one of said internal relationships would result in an 

invalid configuration; 
causing said one of said internal relationships to become 

inactivateable. 

55. The method of claim 54 wherein said step of causing 
40 further comprises the step of excluding the last remaining 

member of said first set of components such that said last 
remaining member cannot be added to said system, said last 
remaining member being the only member of said first set of 
components that has not already been selected. 
45 56. The method of claim 39 wherein said step of trans- 
lating further comprises the step of: 

mapping said intuitive relationships of said external rep- 
resentation into a set of relationships in said internal 
representation. 

50 57. The method of claim 39 wherein said internal repre- 
sentation is stored as a set of bit vectors wherein each bit 
vector includes a bit that corresponds to one of said com- 
ponents of said system definition, the impact of changing the 
number of said components of said system definition thereby 

55 being minimal. 

58. The method of claim 57 wherein said step of validat- 
ing comprising a plurality of bit-level operations. 

59. The method of claim 39 wherein said step of modi- 
fying further comprises the step of updating said configu- 

60 ration state to represent which of said components of said 
system definition are selectable, selected, included, and 
excluded. 

60. A method of configuring a system comprising the 
steps of: 

65 generating a definition for said system, said definition 
containing one or more elements and being conveyed 
graphically using a set of product relationships; 
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generating a set of part relationships between said one or 
more elements, said set of part relationships being 
conveyed graphically using a set of part relationships; 
and 

receiving input from a configuration user; 5 
validating said input based on said definition, said set of 

product relationships, said set of part relationships, and 

a current configuration state; and 
identifying a set of valid configuration options using said 

definition, said set of product relationships, said set of 

part relationships and said current configuration state. 

61. The method of claim 60 wherein said step of identi- 
fying further comprises the steps of: 

determining whether a relationship in said set of relation- 
ships is active; 

modifying said configuration to satisfy said active rela- 
tionship when it is determined that a modification is 
needed; 

making said relationship notActivateable when it is deter- 2 o 
mined that said relationship is not active and the 
activation of said relationship would render the con- 
figuration invalid. 

62. The method of claim 61 wherein said step of deter- 
mining whether a relationship is active further comprises the 2 5 
step of determining whether the elements specified in the 
left-hand side of said relationship are present in said con- 
figuration. 

63. The method of claim 62 wherein said step of deter- 
mining whether the elements specified in the left-hand side 30 
of said relationship are present in said configuration further 
comprises the step of performing a bit-level comparison of 
the bits corresponding to the elements in said left-hand side 

of the relationship with a "selected" bit vector. 

64. The method of claim 61 wherein said relationship is 35 
an includes relationship, said step of modifying further 
comprises the step of including in said configuration ele- 
ments identified in a right-hand side of said relationship. 

65. The method of claim 61 wherein said relationship is 

an excludes relationship, said step of modifying further 40 
comprises the step of marking said elements identified in the 
right-hand side of said relationship as excluded and notSe- 
lectable. 

66. The method of claim 61 wherein said relationship is 

a removes relationship, said step of modifying further com- 45 
prises the step of removing said elements identified in the 
right-hand side of said relationship from said configuration. 

67. The method of claim 61 wherein said relationship is 
a requires choice relationship, said step of modifying further 
comprises the steps of: 50 

determining whether a plurality of elements identified in 
a right-hand side of said relationship are present in said 
configuration such that said relationship is satisfied; 

modifying said configuration to satisfy said requires 
choice relationship when it is determined that only one 55 
path exists to satisfy said relationship and said rela- 
tionship is not already satisfied. 

68. The method of claim 61 wherein said step of making 
said relationship notActivateable further comprises the step 

of marking one or more elements in said left-hand side of 60 
said relationship as noiSclectable. 

69. The method of claim 60 wherein said definition, each 
of said set of relationships, and said current configuration 
state are expressed as bit vectors having bits that correspond 

to elements. 65 

70. The method of claim 60 wherein said step of validat- 
ing further comprises the step of determining whether the 



relationships other than those marked notActivateable in 
said set of relationships can be satisfied. 

71. The method of claim 60 wherein said step of gener- 
ating a definition selects said one or more elements for 
inclusion in said definition, said input is made without 
regard for the order in which said one or more elements are 
selected for said definition. 

72. The method of claim 60 wherein said configuration 
state identifies a set of selected elements and a set of 
selectable elements for said system, said input capable of 
selecting any member of said set of selectable elements and 
being made despite the order in which members of said set 
of selected elements were selected. 

73. An article of manufacture comprising: 

a computer usable medium having computer readable 
program code embodied therein for configuring a sys- 
tem comprising: 

computer readable program code configured to cause a 
computer to generate a definition for said system, 
said definition containing one or more elements and 
being conveyed graphically using a set of product 
relationships; 

computer readable program code configured to cause a 
computer to generate a set of part relationships 
between said one or more elements, said set of part 
relationships being conveyed graphically using a set 
of part relationships; and 

computer readable program code configured to cause a 
computer to receive input from a configuration user; 

computer readable program code configured to cause a 
computer to validate said input based on said 
definition, said set of product relationships, said set 
of part relationships, and a current configuration 
state; and 

computer readable program code configured to cause a 
computer to identify a set of valid configuration 
options using said definition, said set of product 
relationships, said set of part relationships and said 
current configuration state. 

74. The article of manufacture of claim 73 wherein said 
computer readable program code configured to cause a 
computer to identify further comprises: 

computer readable program code configured to cause a 
computer to determine whether a relationship in said 
set of relationships is active; 

computer readable program code configured to cause a 
computer to modify said configuration to satisfy said 
active relationship when it is determined that a modi- 
fication is needed; 

computer readable program code configured to cause a 
computer to make said relationship notActivateable 
when it is determined that said relationship is not active 
and the activation of said relationship would render the 
configuration invalid. 

75. The article of manufacture of claim 74 wherein said 
computer readable program code configured to cause a 
computer to determine whether a relationship is active 
further comprises computer readable program code config- 
ured to cause a computer to determine whether the elements 
specified in the left-hand side of said relationship are present 
in said configuration. 

76. The article of manufacture of claim 75 wherein said 
computer readable program code configured to cause a 
computer to determine whether the elements specified in the 
left-hand side of said relationship are present in said con- 
figuration further comprises computer readable program 
code configured to cause a computer to perform a bit-level 
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comparison of the bits corresponding to the elements in said 
left-hand side of the relationship with a "selected" bit-vector. 

77. The article of manufacture of claim 74 wherein said 
relationship is an includes relationship, said computer read- 
able program code configured to cause a computer to modify 
further comprises computer readable program code config- 
ured to cause a computer to include in said configuration 
elements identified in a right-hand side of said relationship. 

78. The article of manufacture of claim 74 wherein said 
relationship is an excludes relationship, said computer read- 
able program code configuredto cause a computer to modify 
further comprises computer readable program code config- 
ured to cause a computer to mark said elements identified in 
the right-hand side of said relationship as excluded and 
notSelec table. 

79. The article of manufacture of claim 74 wherein said 
relationship is a removes relationship, said computer read- 
able program code configured to cause a computer to modify 
further comprises computer readable program code config- 
ured to cause a computer to remove said elements identified 
in the right-hand side of said relationship from said con- 
figuration. 

80. The article of manufacture of claim 74 wherein said 
relationship is a requires choice relationship, said computer 
readable program code configured to cause a computer to 
modify further comprises: 

computer readable program code configured to cause a 
computer to determine whether a plurality of elements 
identified in a right-hand side of said relationship are 
present in said configuration such that said relationship 
is satisfied; 

computer readable program code configured to cause a 
computer to modify said configuration to satisfy said 
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requires choice relationship when it is determined that 
only one path exists to satisfy said relationship and said 
relationship is not already satisfied. 
81. The article of manufacture of claim 74 wherein said 

5 computer readable program code configured to cause a 
computer to make said relationship notActivateable further 
comprises computer readable program code configured to 
cause a computer to mark one or more elements in said 
left-hand side of said relationship as notSelectable. 

10 82. The article of manufacture of claim 73 wherein said 
definition, each of said set of relationships, and said current 
configuration state are expressed as bit vectors having bits 
that correspond to elements. 

15 83. The article of manufacture of claim 73 wherein said 
code configured to cause a computer to validate further 
comprises program code configured to cause a computer to 
determine whether the relationships other than those marked 
notActivateable in said set of relationships can be satisfied. 

20 84. The article of manufacture of claim 73 wherein said 
code configured to cause a computer to generate a definition 
selects said one or more elements for inclusion in said 
definition, said input is made without regard for the order in 
which said one ore more elements are selected for said 

25 definition. 

85. The article of manufacture of claim 73 wherein said 
configuration state identifies a set of selected elements and 
a set of selectable elements for said system, said input 
capable of selecting any member of said set of selectable 
30 elements and being made despite the order in which mem- 
bers of said set of selected elements were selected. 

***** 
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[57] ABSTRACT 

A platform-independent, usage-independent, location- 
independent quote configuration system is described. The 
present invention, operating in a computer network, is a 
quote configurator comprising, 1) a client module, the client 
module having a platform-independent user interface for 
receiving quote input and command selections from a user, 
the quote input and command selections including product 
selection and selection of information indicative of business 
rules, and 2) a server coupled to the client module across the 
network, the server having access to quote data and business 
rules, the server including a platform-independent server 
interface configured to receive the quote input and command 
selections from the client module, the server validating the 
quote input based on the quote data and the business rules. 
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CLIENT MODULE FORMULATES A QUOTE DATABASE 
QUERY AND SENDS THE QUERY TO THE QUOTE 
CONFIGURATION SYSTEM VIA JAVA SERVER. 
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COST FOR QUOTE IS RECIEVED FROM QUOTE 
DATABASE IN RESPONSE TO THE QUERY AND THE COST 
VALUE IS DISPLAYED ON THE SCREEN BY THE GUI. 
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PROMPT USER TO SELECT A TYPE OF SERVICE. 
710 



SELECTED TYPE OF SERVICE. SELECTED 
PRODUCT TYPE, AND SPECIFIED QUANTITY IS 
SENT FOR VALIDATION TO THE RULES DATABASE 
OF THE QUOTE CONFIGURATION SYSTEM. 
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PLATFORM-INDEPENDENT, USAGE- 
INDEPENDENT, AND ACCESS- 
INDEPENDENT DISTRIBUTED QUOTE 
CONFIGURATION SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to the field of distributed 
computer systems. Specifically, the present invention relates 
to the field of distributed computer systems for configuring 
and providing pricing and quotation information regardless 
of usage or access model and independent of platform type. 

BACKGROUND OF THE INVENTION 

Pricing and quotation information is produced at different 
points and different geographic locations in the sales pro- 
cess. Some of the key triggers used to produce this infor- 
mation include product sales, volume discounts, warranty 
terms, sales/lease contract terms, contract renewals or 
modifications, or special customer requests. Often times, 
quotations or quotes produced as a result of these triggers 
vary substantially based on the business unit or geographic 
location for which a particular quote is targeted. These 
variations are also caused by the different computer 
platforms, systems, usage models and networks used to 
assemble the quote information. Variations can also be 
caused by lack of, or differing, in-depth knowledge of the 
specific business rules and discounts that apply to each 
scenario, location, and business unit. In some cases, dupli- 
cate and redundant information must be reformatted or 
translated to a form compatible with a component of the 
quote generation system. In other cases, information must be 
manually entered. This is due in large part to the rigid data 
input requirements of conventional quote configuration sys- 
tems. 

The limitations in current quote configuration systems 
result in quotes that are difficult to generate and maintain, 
which contain errors that impact the customer and the 
business units, and require manual entry of redundant infor- 
mation at each step of the process. 

Thus, a platform-independent, usage-independent, 
location-independent quote configuration systems which is 
capable of encapsulating the business logic and business unit 
expertise to produce consistent, accurate results is needed. 

SUMMARY OF THE INVENTION 

A platform-independent, usage-independent, location- 
independent quote configuration system is described. The 
present invention, operating in a computer network, is a 
quote configurator comprising, 1) a client module, the client 
module having a platform-independent user interface for 
receiving quote input and command selections from a user, 
the quote input and command selections including product 
selection and selection of information indicative of business 
rules, and 2) a server coupled to the client module across the 
network, the server having access to quote data and business 
rules, the server including a platform-independent server 
interface configured to receive the quote input and command 
selections from the client module, the server validating the 
quote input based on the quote data and the business rules. 

Thus, it is an advantage of the present invention over 
conventional systems that the present invention is based on 
a non-procedural data-driven work flow design. It is a 
further advantage of the present invention that the point of 
service provides a real-time, interactive model for interac- 
tion on all components with the user. It is a further advantage 
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of the present invention that all business rules and expertise 
needed to provide intelligent quoting are encapsulated 
within the quote configuration system, and are transferable 
and usable anywhere on any platform. This enables the 
5 design to be scalable with localization possible to accom- 
modate variations in attributes such as currency and price 
list. It is a further advantage of the present invention that the 
present invention is based on an open architecture to enable 
integration with other systems, business processes and tech- 
10 nologies. It is a further advantage of the present invention 
that the present invention is platform-independent (ex. 
SPARC™, RISC, X86). It is a further advantage of the 
present invention tas; the present invention is independent 
of usage model (ex. nomadic, remote/dial-up, inter- 
15 networked, intra- networked). It is a further advantage of the 
present invention that the present invention is independent 
of access model (ex. stand-alone application, networked 
application, web-based application, web-based applet). 
The features and advantages of the present invention will 
20 be apparent from the accompanying drawings and from the 
detailed description of the preferred embodiment of the 
present invention as set forth below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 

The present invention is illustrated by way of example 
and not limitation in the accompanying drawings, in which: 
FIG. 1 illustrates the system architecture of a prior art 
quote configuration system. 
30 FIG. 2 illustrates the architecture of the quote configurator 
of the preferred embodiment of the present invention. 

FIG. 3 illustrates the operation of the quote configurator 
of the preferred embodiment of the present invention. 
FIG. 4 illustrates a typical data processing system or 
35 platform upon which one embodiment of the present inven- 
tion is implemented. 

FIG. 5 illustrates a sample screen display of the graphical 
user interface of the preferred embodiment. 
40 FIGS. 6 and 7 are flowcharts illustrating the operation of 
the preferred embodiment. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

45 The present invention is a platform-independent, usage - 
independent, location-independent quote configuration sys- 
tem. In the following detailed description, numerous specific 
details are set forth in order to provide a thorough under- 
standing of the present invention. However, it will be 
50 apparent to one of ordinary skill in the art that these specific 
details need not be used to practice the present invention. In 
other instances, well-known structures, interfaces and pro- 
cesses have not been shown in detail in order not to 
unnecessarily obscure the present invention. 
55 FIG. 4 illustrates a typical data processing sysiem or 
platform upon which one embodiment of the present inven- 
tion is implemented. It will be apparent to those of ordinary 
skill in the art, however that other alternative systems of 
various system architectures may also be used. The data 
60 processing system illustrated in FIG. 4 includes a bus or 
other internal communication means 101 for communicating 
information, and a processor 102 coupled to the bus 101 for 
processing information. The system further comprises a 
random access memory (RAM) or other volatile storage 
65 device 104 (referred to as main memory), coupled to bus 101 
for storing information and instructions to be executed by 
processor 102. Main memory 104 also may be used for 
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storing temporary variables or other intermediate informs- of a typical conventional quote processing system is based 

tion during execution of instructions by processor 102. The on a two-tier procedural model with deliberate data syn- 

system also comprises a read only memory (ROM) and/or chronization latency. The client module 120 is typically 

static storage device 106 coup led to bus 101 for storing static large, requiring significant local client resources (such as 

information and instructions for processor 102, and a data 5 disk space, memory, swap space, etc.) to run the quote 

mass storage device 107 such as a magnetic disk drive or configuration system. The client module 120 includes a 

optical disk drive. Data storage device 107 is coupled to bus platform-specific modeling interface 140 and a platform- 

101 and is typically used with a computer readable mass specific user interface 130. The client module 120 is coupled 

storage medium 108, such as a magnetic or optical disk, for to a conventional quote configuration system 110 across a 

storage of information and instructions. The system may 1Q network connection using a transaction messaging mecha- 

further be coupled to a display device 121, such as a cathode nism 145, which is compatible with a conventional quote 

ray tube (CRT) or a liquid crystal display (LCD) coupled to generation engine 150 in quote configuration system 110. 

bus 101 through bus 103 for displaying information to a Quote generation engine 150 is then coupled to quote 

computer user. An alphanumeric input device 122, including configuration engine 160 and quote database 170 across an 

alphanumeric and other keys, may also be coupled to bus interface using an intrasystem communication protocol 155. 

101 through bus 103 for communicating information and 15 Quote database 170 provides the quote data, rules, and 

command selections to processor 102. An additional user screen data used by the quote generation engine 150 along 

input device is cursor control 123, such as a mouse, a with quote configuration engine 160 to generate a quote, 

trackball, stylus, or cursor direction keys coupled to bus 101 Multiple configuration system databases are deployed to 

through bus 103 for communicating direction information accommodate location -specific variables, 

and command selections to processor 102, and for control- 20 This prior art quote configuration methodology has sev- 

ling cursor movement on display device 121. Another device eral disadvantages, which are listed below: 

which may optionally be coupled to bus 101 through bus 103 l. A different platform-specific user interface 130 and 

is a hard copy device 124 which may be used for priming clicnt modu i e m is necessary for each type of hardware 

instructions, data, or other information on a medium such as architecture and operating system (OS) (i.e. platform) upon 

paper, film, or similar types of media. In the preferred 25 which the quote configuration system is deployed, 

embodiment, a cornmunication device 125 is coupled to bus 2 . A different platform-specific user interface 130, client 

101 through bus 103 for use in accessing other nodes of a module 120> messaging mechanism 145, and 
network computer system. This communication device 125 i n t ra systera communication protocol 155 is necessary for 
may include any of a number of commercially available each t of model for which tne le ^^^g^^ 
networking peripheral devices such as those used for cou- tem ^ implemented. In conventional systems, the four 
phng to an Ethernet, token ring, Internet, or wide area usage models commonly utilized are nomadic, remote/dial- 
networtc. U p^ m ter-networked and intra-networked. In a nomadic 

Note that any or all of the components of the system sysicrnj the client module is resident in a portable computer 
illustrated in FIG. 4 and associated hardware may be used in system> which only periodically and asynchronously con- 
various embodiments of the present invention; however ,t nec(s tQ (he configuration system . In a rea10le /dial-up 
will be appreciated by those of ordinary skill in the art that model ^ clfcm modu f e usefJ a ^ modem , £ 

nil™ T ° t f .h" Sys * cm , may b , C USC ? ( for T 0US asynchronously connect with the quote configuration system 

purposes according to the particular implementation. In one .A . . / , . . <, ,. . « , 

embodiment of the present invention/the data processing 110. In an . ^f^^™^-^ client module uses 

system illustrated in FIG. 4 is an IBM® compatible personal Interne! L or W ° rId Web ^ oloco ^ to s .y nchr °- 

computer (PC) or a SUN® SPARC™ Workstation. Proces- 40 nousl y bul ^directly connect to a quote configuration sys- 

sor 102 may be one of the 80X86 compatible raicroproces- tem * ,n an intra-networked model, the client module uses 

sors such as the 80486 or PENTIUM® brand raicroproces- local area network (LAN) or wide-area network (WAN) 

sors manufactured by INTEL® Corporation of Santa Clara, protocols to synchronously and directly connect to a quote 

C a jjf configuration system. 

The software implementing the present invention can be 45 3. A different platform-specific user interface 130, client 

stored in main memory 104, mass storage device 107, or module 120 ' tra nsa<*™ messaging mechanism and intra- 

other storage medium locally accessible to processor 102. It s y slem communication protocol is necessary for each type 

will be apparent to those of ordinary skill in the art that the of access modeI for which the ^ uote configuration system is 

methods and processes described herein can be implemented implemented. The four access models commonly provided 

as software stored in main memory 104 or read only memory 50 m conventional systems are stand-alone application, net- 

106 and executed by processor 102. This software may also worked application, web-based application and web-based 

be resident on an article of manufacture comprising a applet. Stand-alone applications are those software systems 

computer usable mass storage medium 108 having computer ,hal mn on a P latform withoul Detwork connectivity. Net- 

readable program code embodied therein and being readable worked applications are those software systems that run on 

by the mass storage device 107 and for causing the processor 55 a platform with network connectivity and involve network 

102 to perform quote transactions and protocols in accor- "ansactions. The web-based models run on the World Wide 
dance with the teachings herein Web (WWW) P°rtion of the Internet and have dependencies 

Hie preferred embodiment of the present invention is a ° I n bowser-specific implementations in addition to 

platform-independent, usage-independent, location- Platform-specific dependencies. All four of these prior art 

independent quote configuration system, which can be « access models ha ^ e , user interface ^ rendering logic and 

implemented on computer system platforms such as the one data w ** h . IS ^ mte S ra ! ed w , lth the b ™ n ™ and 

illustrated in FIG 4 quote data in the quote configuration system 110. 

4. The system architecture and application programming 

ARCHITECTURE OF THE PREFERRED interfaces (APIs) are proprietary and closed. 

EMBODIMENT 65 5 Tne worlc flow design is strictly procedural in a batch 

FIG. 1 illustrates the typical quote configuration genera- style of processing and has deliberate latency built into the 

tion system currently used in the prior art. The architecture data synchronization model. 
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6. Distribution of the quote configuration system and 
client software, synchronization of quote data and business 
rules, and version control of the system are difficult to 
manage effectively. 

7. A different quote configuration engine 160 and quote 5 
database 170 must be deployed to accommodate each 
location-specific environment. 

8. The user interface 130 requires extensive knowledge of 
the underlying business rules and quote data to generate a 
configuration quote. Q 

9. The prior art design is based on a two-tiered, non- 
distributed/non-networked model. 

FIG. 2 illustrates the quote configurator of the preferred 
embodiment of the present invention. In the present inven- 
tion all common configurations and usage models are 15 
enabled by a single architecture and single user interface 
model, including mobile computing devices (nomadics and 
remote access/dial-ups), local area networks (LANs), wide 
area networks (WANs) and the Internet network. In general, 
these components provide specific functionality for handling 20 
quotation information and for generating quotes. 

The architecture of the present - invention is based on a 
distributed three-tier object-oriented design model as shown 
in FIG. 2. A first tier is a client module 220. The second tier 
is a server 240 and the third tier is quote configuration 2 s 
system 210. 

The client module 220 includes a JAVA™ user interface 
230. JAVA is an object-oriented programming language 
similar to C++ developed by SUN® Microsystems of Moun- 
tain View, Calif. JAVA is unique in that a program written in 30 
JAVA is first compiled into byte-codes and subsequently 
interpreted into machine dependent processor instructions. 
Byte-codes are similar to machine instructions; however, 
byte-codes are not specific to a particular machine or plat- 
form. Thus, JAVA programs can run on any platform that 35 
supports JAVA. It is not necessary to recompile a JAVA 
program to run on a new machine. The JAVA user interface 
230 may therefore be written without platform-specific code 
and without the need to create multiple versions that support 
multiple platforms. 40 

Each tier of the system illustrated in FIG. 2 encapsulates 
all the necessary components for the intended function. All 
interfaces of the present invention are open and public. The 
messaging transport system of the present invention is based 
on socket-level communication protocol using open APIs at 45 
each end of the communications path, such as paths 235 and 
245. Socket-level communication protocol in the context of 
a computer network is well known to those of ordinary skill 
in the art. The user presentation engine of client module 220, 
user interface 230, and JAVA server 240 components are 50 
platform-independent, usage-independent, and access- 
independent and based on a single code source. The JAVA 
server 240 API which interfaces path 245 to quote genera- 
tion engine 250 is an essential element of the present 
invention. Similarly, the JAVA server 240 API which inter- 55 
faces path 235 to client module 220 is also an essential 
element of the present invention. Specifically, the user 
interface component 230 is a graphical user interface (GUI) 
and looks and operates in exactly the same manner inde- 
pendently of platform, usage, and access model. The GUI 60 
230 is fully interactive and intelligent, and requires abso- 
lutely no knowledge of the underlying business rules and 
quote data for a user to generate an accurate configuration 
quote. The interaction of the GUI 230 is fie Id -based, data- 
driven and event-driven. The quote data and rules database 65 
270 also contains new components to support the present 
invention. 
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The client module 220 API to quote generation engine 
250 through JAVA server 240 comprises commands, which 
are formulated in a platform-independent text string format 
and sent to quote generation engine 250 via a socket 
interface of JAVA server 240. A specified port number is 
used by both the client module 220 and the quote generation 
engine 250. Hie quote generation engine 250 interprets these 
commands and sends back its replies to the client module 
220 via the socket interface of JAVA server 240. A detailed 
description of the commands of this API follows. 

Commands 

bload rtssun7b.cab 

This command makes the quote generation engine 250 
read and load (in memory) all information contained in the 
rlssun7b.cab file. This file contains all business rules and 
screen rendering information needed by the quote generation 
engine 250. 

BEruntimelnit streamout 

This command initiates runtime a communication proto- 
col by the quote generation engine 250. The 'streamout* 
argument is a parameter that tells the quote generation 
engine 250 to use its socket layer interface for communica- 
tion. 

BEinsPickBylndex <field> <idx> 1 

This command instructs the quote generation engine 250 
to pick a <field> with index <idx> and return all information 
stored for this field. The <field> argument can be any of the 
following in the preferred embodiment: 



Contract PriceBook MarketingServices 

RcplcHrdwrPrts CatDcfPrty UnlimPhoncSprt 

OnSiteResp OnSiteResp2_hr OnSileCov7_24 

PrefCustomer End User MaintMon 
Multiyr 



The <indx> argument is an integer value representing the 
index of the specified field. 
Example: BEinsPickBylndex Contract 2 1 

(This sample command requests the quote generation 
engine 250 to retrieve all the information about the 
second field for contracts.) 
BEinsValueSet NumberUsers val Yal <qty> 

This command sets the quantity of products specified by 
the user. The <qty> argument is an integer value that 
represents the quantity of products. 
BEreset 

This command forces the quote generation engine 250 to 
ignore all previous input and start from the very beginning. 
BEprequote 

This command produces a pre-quote listing for the current 
session. 
ueQuote 

This command produces a final quote for the current 
session. 

BEinsWhy <field> <state> 

This command returns an explanation as to why a stale of 
contradiction now exists for this <field>. 

Example: BEinsWhy OnSiteResp2_hr 2 (This example 
asks why is there a contradiction in 2-hr response 
time?) 

BEviewSummaryGet <windowname> 

This command returns comprehensive information about 
a set of fields that logically belong to <windowname>. 
Example: BEviewSummaryGet win4 (The quote genera- 
tion engine 250 returns all current information and 
states of fields that belong to window 4.) 
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These interfaces and commands of the preferred embodi- and 7, the user may iteratively select or edit the selections 

ment are only a subset of the entire API; however, these described in blocks 614-712. 

commands are sufficient for an operable system. It will be 3. User selects the types of coverage desired, 

apparent to those of ordinary skill in the art that other Referring now to FIG. 7, selection of the type of coverage 

commands or command arguments may also be provided. 5 provides an adjustment in total quote cost based on the type 

Conversely, the interfaces 265 and 275 to the quote con- service selected (blocks 710 and 712 shown in FIG. 7). This 

figuration engine 260 and quote database 270, respectively, selection of type of coverage identifies a set of business rules 

are conventional interfaces. which is applied to the request. If this type of coverage is not 

available for the selected product type and the specified 

OPERATION OF THE PREFERRED 10 quantity, the business rule of the quote configuration system 

EMBODIMENT quote database will indicate an invalid condition which is 

FIG. 3 illustrates the operation of the quote configurator S™ m ™F a H !d V}* GV J 230 Wa JAVA servcr 240 $ {ock 

of the preferred embodiment of the present invention. The 714) ' ™ 1S ( . inVa!ld ^ 0 ^™, C ™** a pop_up scrcCD t0 

client module 220 communicates with JAVA server 240 and -T^fll LTnf^r / Y ^ ^ 

quote configuration system 210 in the context of the World is * ° md ^igahon/event assistance for the user. 

Wide Web (WWW) and the Internet 320. 17* client module K n ?£* 1™ ^ ^ Wn * tl0ns ' Tu" 

220 may also gather other business data from repository 340. DgS ^ hintS , Can b ° f ^ y " t"^! * 

Network users of the present invention such^s nomadic 'Ste^fi^ifi'S^SJ^*^ 1 *° ™* 

users 350, Internet users 360, or intranet users 370 may qU t ° tC confi S uraUo " 21 » ™ "J"?™ 1 commum- 

*u v * a i niA c ^ , • • . ™ catlon regarding of the sta e of the GUI 230 and selected 

access the client module 220 of the present invention via 20 „ wnfc/ u »iowcu 

JAVA client/net browser 330. Once these network users cvents/o P Uons - the uscr caQ 'Wide" the suggestion/ 

connect to the client module 220, the users may request and WamiDg P ° P " Up ,f "T mCSSagC ^ prOC f * Wl th the ^ 

view quote information. Quote information may also be accommodate local variations/ 

printed, faxed, filed, or emailed via output devices con- , ... ". 

nected to client module 220. 25 In addltlon |° event-driven assistance, the user can get 

- en • _ , ... . , A on-demand assistance on invalid conditions, additional hints 

■me fol owing sample scenario will demonstrate an and warni b ^ me -contradic ions" button as 

example of the quote configurate process of the present shown on the screen sample shown in FIG. 5. After the quote 

ronton for generating a custom quote from both the use, adjusted based on , he ^ 

and system perspective. This example w,U highlight the qua nuty. and type of service, me Adjusted quotV is displayed 

essentialstepsof the present mvention asappropnate. In this » ^ me Lr on L screen (block 722). ^ user can 

desenpuon, no diction ,s made regarding location of the ^ me fc „ a „ V ^ ^ ^ fi 

user/system, access method of the user/system, or the type of process ^uugmauou 

platform on which either the user or system exists. The same -n,.' u ,u t n • JJV , ., , 

process and model will work regardless of platform, access ™ C ^ ^ fol,owin 8 ^monal options prov,ded at 

type, or usage model. FIGS. 2 and 3 are referenced in » i*"™* ^ ^ ss »n the preferred embodi- 

combination with the flow diagrams of FIGS. 6 and 7 to ? I * } the qU ° te '° " 

illustrate the operation of the present invention. In addition, f ax ^ nab ed definition using a conventional facsimile 

the screen sample shown in FIG. 5 also referenced. deV1C6; 3)e - m 1 al the qu ? te to ., a networ ked destmat.on using 

r\ •.•.- <• .u i- . j , r . a conventional electronic mail system; 4) print the quote to 

On initiation of the client module 220 of the present asystem-acknowledged printer; or S)saveme quote to a file, 

invention by the user the GUI 230 establishes a socket Buttons for selecting these options are shown in FIG. 5 and 

connection with the JAVAserver 240 m real-time and loads me interface supportin g ^ options fe shown m nG 3 

an initial data set. In block 610, shown in FIG. 6, a main -n,,„ „ „,„, F • . . . . , , 

screen or window of the GUI 230 is then auto-populated ^tilS^'^^T "? 8 c - ,nd °P cn <! en \ and 

with a series of default values as specified by the JAVA GUI h«^H ^ fi configuration system has been 

230, based on the encapsulated business rules. One such 45 H^^f^.T"* 6 ?^' ■T^fil^ n ^ 

sample screen is illustrated in FIG. 5. These default values ° P lm f C,P 

• i j n • r • * t it o -t ia.l- . invention. Numerous modifications in form and oxtail ma v 

include Price Lists; Travel Zone; Service Level. At this point Ktt „ nAa kw f , ... . . . ; y 

. . , , . - be made by those of ordinary ski 1 in the art without 

in the process, the user only needs o select a product type ^^w;™ c *u . * , . * « " lluUi 

n ™,««t-«« • a t - » l* departing from the scope of the present invention. Although 

and enter a quantity in order to receive a quote. In this „,£ inve 6 mion has ^ reU|iM (o a »J 

example, me user win oe producing a custom quote. embodiment, it should not be considered so limited. Rather, 

1. User selects the product. the present invention is limited only by the scope of the 
The user is prompted in block 612, shown in FIG. 6, with following claims. 

a pick list to select a product type or the user can ask for We claim: 

additional information/help. On selection of the product type 55 1 . In a computer network, a quote configurator compris- 

from the pick list presented by the GUI 230, the GUI 230 ing: 

logic updates the screen with appropriate user-selectable a client module, the client module having a user interface 

options, key hints and other information intended to assist to receive quote input and command selections from a 

the user with creation of the custom quote based on the user user, the quote input and command selections including 

selection of product type (block 614). 60 product se i ection and selection of information indica- 

2. User enters a quantity. tive of business rules; and 

On entry of the quantity (block 616), the GUI 230 logic a server coupled to the client module across the network, 

determines the initial total cost for the quote by using the the server having access to quote data and business 

JAVA server 240 and socket protocol via path 245 to query rules, the server including a server interface configured 

the quote database 270 (block 618), perform the calculations 65 to receive the quote input and command selections 

and update the appropriate portion of the screen of the GUI from the client module, the server validating the quote 

230 (block 620). As denoted by bubble B shown in FIGS. 6 input based on the quote data and the business rules, 
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said user interface and said server interface being com- 
prised of platform independent byte-codes. 

2. The quote configurator as claimed in claim 1 wherein 
the server interface is a platform-independent, usage- 
independent and access- independent transport protocol for 
messaging quote data and business mles between the server 
and the client module. 

3. The quote configurator as claimed in claim 1 wherein 
the user interface is a platform-independent, usage- 
independent and access-independent graphical user inter- 
face. 

4. The quote configurator as claimed in claim 1 wherein 
the client module is JAVA compatible. 

3. The quote configurator as claimed in claim 1 wherein 
the server is JAVA compatible. 

6. The quote configurator as claimed in claim 1 wherein 
the client interface byte-codes are interpreted for operation 
on a particular client platform. 

7. The quote configurator as claimed in claim 1 wherein 
the server interface byte-codes are interpreted for operation 
on a particular server platform, 

8. The quote configurator as claimed in claim 1 wherein 
the user interface includes a screen display configured for 
product selection and selection of information indicative of 
business rules. 

9. The quote configurator as claimed in claim 1 wherein 
the client module further includes an interface to a nomadic 
user. 

10. The quote configurator as claimed in claim 1 wherein 
the client module further includes an interface to an Internet 
user. 

11. The quote configurator as claimed in claim 1 wherein 
the client module further includes an interface to an intranet 
user. 

12. A method for configuring quotes comprising: 
receiving quote input and command selections from a user 

via a user interface in a client module, the quote input 
and command selections including product selection 
and selection of information indicative of business 
rules; 

sending said quote input and command selections to a 
server across a server interface, said user interface and 
server interface being comprised of platform indepen- 
dent byte-codes; 
accessing quote data and business rules; and 
validating the quote input based on the quote data and the 
business rules. 

13. The method as claimed in claim 12 wherein the 
sending further includes preparing the quote input and 
command selections in a platform-independent, usage- 
independent and access-independent transport protocol for 
transport to the server. 

14. The method as claimed in claim 12 wherein the user 
interface is a platform-independent, usage-independent and 
access-independent graphical user interface. 
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15. The method as claimed in claim 12 wherein the client 
module is JAVA compatible. 

16. The method as claimed in claim 12 wherein the server 
is JAVA compatible. 

17. The method as claimed in claim 12 further including 
interpreting the client interface byte-codes for operation on 
a particular client platform. 

18. The method as claimed in claim 12 further including 
interpreting the server interface byte-codes for operation on 
a particular server platform. 

19. The method as claimed in claim 12 further including 
receiving a product selection and receiving a selection of 
information indicative of business rules. 

20. The method as claimed in claim 12 further including 
receiving input from a nomadic user. 

21. The method as claimed in claim 12 further including 
receiving input from an Internet user. 

22. The method as claimed in claim 12 further including 
receiving input from an intranet user. 

23. On a computer useable medium having computer 
readable code embodied therein, a client module for causing 
the computer to configure quotes, the client module com- 
prising: 

computer readable program code configured to cause the 
computer to receive quote input and command selec- 
tions from a user via a user interface, the quote input 
and command selections including product selection 
and selection of information indicative of business 
rules; 

computer readable program code configured to cause the 
computer to send said quote input and command selec- 
tions to a remote server across a server interface; and 

computer readable program code configured to cause the 
computer to receive validation information from the 
remote server indicating whether the quote input is 
valid based on quote data and the business rules, 

said user interface and said server interface being com- 
prised of platform independent byte-codes. 

24. On a computer useable medium having computer 
readable code embodied therein, a server for causing the 
computer to configure quotes, the server comprising: 

computer readable program code configured to cause the 
computer to receive quote input and command selec- 
tions from a remote client module across a server 
interface; 

computer readable program code configured to cause the 
computer to access quote data and business rules; and 

computer readable program code configured to cause the 
computer to validate the quote input based on the quote 
data and the business rules, 

said server interface being comprised of platform inde- 
pendent byte-codes. 
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